Method and apparatus for authenticating data relating to usage of a gaming device

ABSTRACT

Methods and apparatus for managing and authenticating usage of features of gaming devices is presented. The methods include tracking and/or accumulating usage data relating to gaming device features, determining an authentication code based on the usage data, outputting the authentication code to an operator for transmission to an interested party, and verifying the authentication code. The present invention allows regulatory agencies and manufacturers of gaming devices to reliably verify the usage of individual features of gaming devices without having to rely upon a casino to report the usage data.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of U.S. patent applicationSer. No. 10/682,062, filed Oct. 9, 2003, entitled “METHOD AND APPARATUSFOR AUTHENTICATING DATA RELATING TO USAGE OF A GAMING DEVICE”, which isa continuation-in-part of U.S. patent application Ser. No. 10/419,478,filed Apr. 18, 2003, entitled “METHOD AND APPARATUS FOR ENABLING APLAYER TO SELECT FEATURES ON A GAMING DEVICE”;

which is also a continuation-in-part of U.S. patent application Ser. No.10/420,068, filed Apr. 21, 2003, entitled “METHOD AND APPARATUS FORMANAGING FEATURES ON A GAMING DEVICE”;

and which also claims the benefit of U.S. Provisional Patent ApplicationNo. 60/417,415 filed Oct. 9, 2002, entitled “METHOD AND APPARATUS FORAUTHENTICATING DATA RELATING TO USAGE OF A GAMING DEVICE”.

Each of the above applications is incorporated by reference in itsentirety.

The present Application is related to the following commonly-owned,co-pending U.S. patent applications:

-   -   (i) U.S. patent application Ser. No. 09/603,677, filed Jun. 26,        2000, entitled “METHOD AND APPARATUS FOR SELECTING A        SUPPLEMENTAL PRODUCT TO OFFER FOR SALE DURING A TRANSACTION”,        the entirety of which is incorporated by reference herein for        all purposes;    -   (ii) U.S. patent application Ser. No. 09/993,228, filed Nov. 14,        2001, entitled “METHOD AND APPARATUS FOR DYNAMIC RULE AND/OR        OFFER GENERATION”, the entirety of which is incorporated by        reference herein for all purposes;    -   (iii) U.S. Reissue application Ser. No. 10/222,523, filed Aug.        16, 2002, entitled “GAMING DEVICE FOR OPERATING IN A REVERSE        PAYOUT MODE AND A METHOD OF OPERATING SAME”, the entirety of        which is incorporated by reference herein for all purposes;    -   (iv) U.S. application Ser. No. 09/879,299, filed Jun. 12, 2001,        entitled “SYSTEM AND METHOD FOR AUTOMATED PLAY OF MULTIPLE        GAMING DEVICES”, the entirety of which is incorporated by        reference herein for all purposes;    -   (v) U.S. application Ser. No. 10/121,243, filed Apr. 11, 2002,        entitled “METHODS AND SYSTEMS FOR FACILITATING PLAY AT A GAMING        DEVICE BY MEANS OF THIRD PARTY OFFERS”, the entirety of which is        incorporated by reference herein for all purposes;    -   (vi) U.S. application Ser. No. 10/419,304 filed Apr. 18, 2003,        entitled “GAMING DEVICE METHODS AND APPARATUS EMPLOYING MODIFIED        PAYOUTS”, the entirety of which is incorporated by reference        herein for all purposes;    -   (vii) U.S. application Ser. No. 10/417,436 filed Apr. 16, 2003,        entitled “METHOD AND APPARATUS FOR OPTIMIZING THE RATE OF PLAY        OF A GAMING DEVICE”, the entirety of which is incorporated by        reference herein for all purposes;    -   (viii) U.S. application Ser. No. 10/361,201, filed Feb. 7, 2003,        entitled “GAMING DEVICE AND METHOD OF OPERATION THEREOF”, the        entirety of which is incorporated by reference herein for all        purposes;    -   (ix) U.S. application Ser. No. 10/414,511 filed Apr. 15, 2003,        entitled “METHOD AND APPARATUS FOR BONUS ROUND PLAY”, the        entirety of which is incorporated by reference herein for all        purposes;    -   (x) U.S. application Ser. No. 10/328,116, filed Dec. 20, 2002,        entitled “METHOD AND APPARATUS FOR OUTPUTTING OUTCOMES OF A        GAMING DEVICE”, the entirety of which is incorporated by        reference herein for all purposes;    -   (xi) U.S. application Ser. No. 10/254,831, filed Sep. 25, 2002,        entitled “METHOD AND APPARATUS FOR LINKED PLAY GAMING”, the        entirety of which is incorporated by reference herein for all        purposes;    -   (xii) U.S. application Ser. No. 10/007,874, filed Nov. 12, 2001,        entitled “ELECTRONIC AMUSEMENT DEVICE AND METHOD FOR PROPAGATING        A PERFORMANCE ADJUSTMENT SIGNAL”, the entirety of which is        incorporated by reference herein for all purposes; and    -   (xiii) U.S. application Ser. No. 10/322,107, filed Dec. 18,        2002, entitled “FREE LONG DISTANCE CALLS ON SLOT MACHINES”, the        entirety of which is incorporated by reference herein for all        purposes.

BACKGROUND

The present invention relates generally to methods and apparatus forencrypting and authenticating data relating to usage of features ofgames and of gaming devices.

Gaming devices (e.g., reeled slot machines, video slot machines, videopoker machines, video keno machines, video blackjack, video bingomachines, etc.) generate more than $15 billion per year in revenue forcasinos in the United States alone. This figure accounts for more thanhalf of the gaming revenue for a typical United States casino. Thesituation is similar in other countries in which gaming devices arepopular, such as Australia. Accordingly, casino operators and otheroperators of gaming devices are interested in increasing the enjoymentof playing gaming devices in order to maintain or increase this level ofrevenue.

Gaming device manufacturers often lease gaming devices to casinos for apercentage of the revenues generated by these machines. Manufacturersmarket gaming devices in many different ways. Examples include sellingtheir gaming devices and conversion kits to casinos and other gamingdevice operators. In another example, manufactures lease their gamingdevices to casinos and other gaming device operators for lease paymentsbased upon, for example, (1) a percentage of the net win of the gamingdevice, or (2) based upon fixed daily fees. A percentage of net winarrangement allows manufacturers to share in the earnings of thesegaming devices, and both types of lease arrangements permitmanufacturers to generate a recurring revenue stream.

Manufacturers refer to gaming devices that are operated under thesetypes of lease arrangements as “participation games.” Note that in sucharrangements, manufacturers typically must rely on the casinos toaccurately report the revenues generated by the gaming devices. Casinopersonnel may intentionally, or unintentionally, misrepresent the usageof a participation gaming device and thereby reduce the value of a leasepayment for a gaming device. Manufacturers would rather not have to relyon casinos to accurately report the revenues generated by a gamingdevice.

Manufacturers sometimes allow casinos or other operators to test a newtype of gaming device for a limited period of time (e.g., 30 days). Thisenables the casino to determine whether the new type of gaming devicewill generate sufficient revenues to be worth leasing or purchasing. Ifa casino is dissatisfied with a new type of gaming device, they maycancel any plans to lease or purchase the machine and retain anyrevenues that were gained during the trial period. Note that in thissituation as well, manufacturers are typically in the disadvantageousposition of relying upon the casinos to accurately report the revenuesgenerated by the gaming devices.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1A is a flowchart depicting an exemplary process consistent withone or more embodiments of the present invention.

FIG. 1B is a flowchart depicting an exemplary process consistent withone or more embodiments of the present invention.

FIG. 1C is a flowchart depicting an exemplary process consistent withone or more embodiments of the present invention.

FIG. 1D is a flowchart depicting an exemplary process consistent withone or more embodiments of the present invention.

FIG. 2A is a block diagram of an exemplary system consistent with one ormore embodiments of the present invention.

FIG. 2B is a block diagram of another exemplary system consistent withone or more embodiments of the present invention.

FIG. 3 is a block diagram of an exemplary computer consistent with oneor more embodiments of the present invention.

FIG. 4 is a block diagram of an exemplary gaming device consistent withone or more embodiments of the present invention.

FIG. 5 is a table illustrating an exemplary data structure of a featuredatabase consistent with one or more embodiments of the presentinvention.

FIG. 6 is a table illustrating an exemplary data structure of acondition database consistent with one or more embodiments of thepresent invention.

FIG. 7 is a table illustrating an exemplary data structure of a gamingdevice database consistent with one or more embodiments of the presentinvention.

FIG. 8 is a table illustrating an exemplary data structure of a playerdatabase consistent with one or more embodiments of the presentinvention.

FIG. 9A is a table illustrating an exemplary data structure of aperformance database consistent with one or more embodiments of thepresent invention.

FIG. 9B is a table illustrating another exemplary data structure of aperformance database consistent with one or more embodiments of thepresent invention.

FIG. 9C is a table illustrating another exemplary data structure of aperformance database consistent with one or more embodiments of thepresent invention.

FIGS. 9D and 9E is a table illustrating another exemplary data structureof a performance database consistent with one or more embodiments of thepresent invention.

FIG. 10A is a table illustrating an exemplary data structure of apayment database consistent with one or more embodiments of the presentinvention.

FIGS. 10B and 10C is a table illustrating another exemplary datastructure of a payment database consistent with one or more embodimentsof the present invention.

FIG. 11 is a plan view of an exemplary gaming device consistent with atleast some embodiments of the present invention.

FIG. 12 is a flowchart depicting an exemplary process consistent withone or more embodiments of the present invention.

FIG. 13A is a block diagram of an exemplary gaming device consistentwith one or more embodiments of the present invention.

FIG. 13B is a block diagram of an exemplary gaming device consistentwith one or more embodiments of the present invention.

FIG. 14 is a table illustrating an exemplary data structure of an eventdatabase consistent with one or more embodiments of the presentinvention.

FIG. 15 is a table illustrating an exemplary data structure of a gamedata database consistent with one or more embodiments of the presentinvention.

FIG. 16 is a table illustrating an exemplary data structure of anauthentication code database consistent with one or more embodiments ofthe present invention.

FIG. 17A is a block diagram of another exemplary system consistent withone or more embodiments of the present invention.

FIG. 17B is a block diagram of another exemplary system consistent withone or more embodiments of the present invention.

FIG. 17C is a block diagram of another exemplary system consistent withone or more embodiments of the present invention.

FIG. 17D is a block diagram of another exemplary system consistent withone or more embodiments of the present invention.

FIG. 18 is a block diagram of an exemplary authentication serverconsistent with one or more embodiments of the present invention.

FIG. 19 is a table illustrating an exemplary data structure of a gamingdevice database consistent with one or more embodiments of the presentinvention.

FIG. 20 is a table illustrating an exemplary data structure of a codeverification database consistent with one or more embodiments of thepresent invention.

FIG. 21 is a flowchart depicting an exemplary process consistent withone or more embodiments of the present invention.

FIG. 22 is a flowchart depicting an exemplary process consistent withone or more embodiments of the present invention.

FIG. 23 is a flowchart depicting an exemplary process consistent withone or more embodiments of the present invention.

FIGS. 24A and 24B are plan views of an exemplary gaming deviceconsistent with at least some embodiments of the present invention.

DETAILED DESCRIPTION

The present invention addresses drawbacks of the prior art by providinga method and apparatus for encoding and/or verifying data descriptive ofthe usage of gaming devices and gaming device features. According tosome embodiments, the invention provides a method of guaranteeing thatusage data from a game machine is authentic. When the invention is usedproperly, it is extremely difficult for an attacker (e.g., anuntrustworthy casino) to misrepresent usage data to an interested party(e.g. a game manufacturer, a regulatory group).

According to some embodiments, the invention includes a gaming device orgame machine (e.g., a slot machine, a video poker machine, a pachinkomachine). Players may operate the game machine to play games (e.g. gamesof chance) and possibly win prizes (e.g. cash prizes). The gaming devicemay track usage data relating to operation of the game machine,including coin-in, revenues, payouts, activated/deactivated features,offers, player inputs, outcomes, and other events or statistics.According to some embodiments, this usage data may be communicated to aninterested party (e.g., for use in determining a licensing fee or taxpayment). In some embodiments, the usage data my be encrypted into acode before it is communicated.

According to some embodiments, a gaming device may generate anauthentication code based on the usage data. This authentication codemay be generated using a variety of different cryptographic andnon-cryptographic protocols, which are described herein. Generating anauthentication code may include compressing or encrypting usage data.For example, a game machine may compute a cryptographic hash of a set ofusage data, which may be encrypted with a secret key. It is anticipatedthat since an attacker (e.g. an untrustworthy casino employee) does notknow this secret key, the attacker would be unable to forge acounterfeit authentication code.

According to some embodiments, an authentication code may be output froma game machine. For example, a game machine may print out anauthentication code on a piece of paper, display an authentication codeon an LCD screen, or transmit an authentication code to anauthentication server using a communication network.

According to some embodiments, an authentication code may be verifiedusing an authentication server. An authentication server may be acomputer server operated by an interested party. Verifying anauthentication code may include decrypting at least a portion of theauthentication code. For example, an authentication server may decryptan authentication code using a decryption key that corresponds to asecret key used by a game machine to produce an authentication code.Verifying an authentication code may also include comparing informationincluded in the authentication code (e.g., usage data, a timestamp) toone or more expected values (e.g., usage data that was indicated to theauthentication server as part of a lease payment).

According to some embodiments, the system may guarantee that usage datafrom a game machine is authentic if an authentication code correspondingto the usage data is verified by an authentication server.

In accordance with some embodiments of the present invention, theoperation of a gaming device (and/or of a game provided on the gamingdevice) may be affected by various parameters, options, and otherfeatures enabled for use on the gaming device. As discussed herein, suchfeatures may enhance various aspects of a player's experience at thegaming device. For example, a feature may be used on a gaming device toalter a mode of operation of the gaming device (e.g., to alter a mode ofoperation of a game, to change how information is communicated to aplayer, to modify how payouts are determined for a player (e.g., bychanging a payout table for a game), or to modify the types of offersthat can be made to a player at the gaming device. As indicated above,the gaming device may track usage data relating to feature use forreporting to interested parties.

Applicants have recognized that, in some embodiments, operators ofgaming devices may find it appealing to be able to take advantage ofmethods and apparatus for determining which features (or combinations offeatures) to enable for use on one or more gaming devices. Likewise,manufacturers of gaming devices may wish to encourage the operators toexperiment with different features by giving them the flexibility to doso. For example, some types of operators may find it appealing to beable to determine which one or more features of a plurality of featuresare likely to be most appealing to players, to increase revenues of agaming device, and/or to increase profitability of a gaming device.

Some types of gaming devices offer one or more different types of games.Applicants have also recognized that owners and operators of gamingdevices may also benefit from methods and apparatus for determiningwhich games (or combinations of games) to make available to players ofgaming devices. U.S. patent application Ser. No. 10/420,069, filed Apr.18, 2003, entitled “METHOD AND APPARATUS FOR MANAGING PERFORMANCE OFMULTIPLE GAMES”, the entirety of which is incorporated by referenceherein for all purposes, relates generally to managing the availabilityof different games on a gaming device. The present application, incontrast, relates generally to reporting authenticable informationrelated to managing features for enhancing the operation of gamingdevices and/or features for enhancing the operation of available games.

Applicants have recognized that owners and operators of gaming devicesmay benefit from being able to determine and report various measures ofthe performance of a feature. For example, an indication of an amountthat an enabled feature has been used on a slot machine, or anindication of how much revenue was taken in at a gaming device at whichthe feature is enabled, may be useful in managing one or more featureson one or more gaming devices (e.g. in determining whether to disable aparticular feature or to keep it enabled on one or more gaming devices).In another example, by tracking and reporting information related to useof a gaming device, an increased profitability of the gaming device maybe correlated to one or more features enabled at the gaming device. Inanother example, by tracking and reporting authenticable informationrelated to use of a gaming device, participation licensing arrangementsbetween operators and manufactures may provide terms that specifypayments based upon the actual increased profitability of the gamingdevice due to a particular licensed feature. In another example, thirdparties may license features to manufactures for inclusion in gamingdevices under a participation-type arrangement whereby the third partymay earn fees based upon the actual increased profitability of thegaming device due to the particular licensed feature.

Applicants have recognized that owners and operators of gaming devices,as well as providers of features for use on gaming devices, may find itappealing to be able to reliably determine a payment based on theperformance of a feature (and/or of a gaming device on which the featureis enabled). For example, some operators of gaming devices may benefitfrom being able to pay a provider of a feature an amount that is basedon how long the feature is enabled for use, how many machines areenabled to provide the feature, or how often the feature is actuallyused by players. Thus, gaming device operators may be able to enter intoperformance-based agreements with providers in which the operator cancompensate the provider based on a cost per use of the feature, or acost per time the feature is in use (or merely enabled for use). Inanother example, as indicated above, some operators or manufacturers mayfind it appealing to be able to determine a payment based on an increasein the use or profitability of a gaming device.

Applicants have also recognized that enhancing the operation of a gamingdevice by enabling and/or disabling the use of one or more particularfeatures (or combinations of features) on the gaming device may serve todistinguish the gaming device, and may provide a more satisfyingentertainment experience to players, thus attracting more players tosuch a gaming device.

Applicants have also recognized that modifying the experience of aplayer at a gaming device, by enabling and/or disabling the use of oneor more particular features with the gaming device, may serve toincrease the player's use of the gaming device, leading to increasedrevenues for owners and operators of gaming devices, and may increasethe profitability of the gaming device.

Applicants have further recognized that manufacturers, owners, andoperators of gaming devices may benefit from a degree of flexibility indetermining which of a plurality features should be available for use ona gaming device. Applicants have also recognized that manufacturers,owners, and operators of gaming devices may find it appealing to have afeature automatically enabled or disabled on a gaming device inaccordance with various predetermined conditions. Likewise, Applicantshave recognized that automatically tracking and reporting enabling anddisabling of features in a reliable and/or authenticable manner isuseful to operators, manufacturers, and feature providers.

Accordingly, the present invention comprises systems and methods formanaging features for use on gaming devices as well as tracking,encoding, reporting, and authenticating the use of such features. Inaccordance with one or more embodiments, a feature is enabled for use onone or more gaming devices, and an indication of performance of thefeature (e.g. a number of times the feature is selected for use byplayers) is determined, encoded, and output. In some embodiments, apayment (e.g., a royalty fee) is also determined based on theperformance of the feature.

For example, according to an exemplary embodiment, a feature forproviding an enhanced mode for automated play on a slot machine islicensed by a casino from the developer of the feature. The casino thenenables the feature for use on five slot machines in the casino, makingthe feature available to players playing the machines. During a brieftrial period of two days, different types of information relating tointeractions of players with the slot machines (e.g., playerinformation, game information, information about the slot machines,information about the players' use of features) are transmitted to acasino server and stored. During the two-day period, for example, theautomated play mode was activated twenty-five times by eighteendifferent players. Some players selected the feature from a displayedlist of “New Releases” features. One player was displayed an offerinviting her to switch to automated play mode, and pressed an “OK”button on the slot machine's touch screen to accept the offer.

On one of the slot machines, the feature was in use for a total of threehours during the two-day period. The average coin-in per hour for thetwo-day period while the feature was enabled was higher than themachine's average during the same two days of the previous week; theaverage coin-in per hour for the three hours while the feature wasactually in use (e.g., when a player was playing the slot machine inautomated play mode) was higher yet.

After the two-day trial period, a payment was determined based on thenumber of times the mode was selected for use and a per-use rate, andthe casino arranged to have the payment provided to a licensor whoprovided the feature. Along with the payment, the casino provided thelicensor with five authentication codes, one generated by each of thefive slot machines that each included encrypted data representative ofthe number of times the mode was selected for use on each machine. Uponreceipt of the payment and the five codes, the licensor verified thatthe payment amount was correct based upon the authentication codes. Thecasino, pleased with the performance of the feature, choose to enablethe feature on all of its electronic reeled slot machines.

A feature, as used herein unless expressly indicated otherwise,comprises an enhancement, option, parameter, or mode that may affect howa gaming device operates and/or may affect how a game operates on agaming device. A feature (e.g., a virtual assistant enhancement, anenhancement allowing a player to make telephone calls at a gamingdevice) may be contrasted with a game (e.g. a type of video poker game),which may be affected by a feature (e.g., by allowing for a virtualassistant in a video poker game).

Features may affect various operations of a game and/or a gaming device,such as the way a game is played, the way play of a game and/orinformation about a game are displayed, the way outcomes are determinedin a game, and the way information about outcomes are displayed orotherwise communicated to a player. Reference may be made herein to someexemplary features for illustrative purposes; however, the operations ofvarious games and gaming devices with one or more features in use may bedependent on the specific feature or active features, and may not bedescribed in detail herein. Examples of features include, but are notlimited to:

-   -   (i) Features that enhance play of a gaming device by modifying a        payout mode of the gaming device. A reverse payout mode which is        appropriate for enhancing the operation of a gaming device in        accordance with one or more embodiments of the present invention        is disclosed in U.S. Reissue application Ser. No. 10/222,523,        filed Aug. 16, 2002, entitled “GAMING DEVICE FOR OPERATING IN A        REVERSE PAYOUT MODE AND A METHOD OF OPERATING SAME”, the        entirety of which is incorporated by reference herein for all        purposes.    -   (ii) Features that affect the operation of a gaming device by        allowing for the allocation of wagers by players. For example,        an activated feature may allow a player to divide an initial        wager into a number of pieces designated by the player, with        each wager portion corresponding to a uniquely determined        outcome and payout. The size of the payouts may be adjusted by        the size of the wager portion, or the probability of a winning        outcome appearing could be correspondingly lowered.    -   (iii) Features that provide for automated play of one or more        gaming devices in which the player is able to pre-pay for a        series of reel spins and then watch as the slot machine        determines outcomes for each spin without the need for the        player to pull a handle or depress a spin button. A feature        enhancing the operation of a gaming device to provide for        automated play of one or more gaming devices is disclosed in        U.S. application Ser. No. 09/879,299, filed Jun. 12, 2001,        entitled “SYSTEM AND METHOD FOR AUTOMATED PLAY OF MULTIPLE        GAMING DEVICES”, the entirety of which is incorporated by        reference herein for all purposes.    -   (iv) Features that allow for an offer to be presented to a        player at a gaming device. Offers could include discounts at        casino restaurants or showrooms, free hotel room nights, and the        like. Offers could include a payment to a player in return for        an action such as buying a pair of show tickets, providing a        source of gambling funds for the player and incremental business        for other casino revenue centers (e.g. hotel, restaurants,        show). A feature enhancing the operation of a gaming device in        order to allow for one or more offers to be presented to a        player at a gaming device, is disclosed in U.S. application Ser.        No. 10/121,243, filed Apr. 11, 2002, entitled “METHODS AND        SYSTEMS FOR FACILITATING PLAY AT A GAMING DEVICE BY MEANS OF        THIRD PARTY OFFERS”, the entirety of which is incorporated by        reference herein for all purposes.    -   (v) Features that enhance the operation of a gaming device by        allowing the player to eliminate the payouts associated with a        set of outcomes in exchange for a reduced cost per play (e.g.,        at a cost less than a normal wager). For example, the player        could elect to buy one or more outcomes of a slot machine in        which only the top jackpot was enabled for payment—at a cost        significantly lower than the normal cost of a reel spin at that        gaming device. A gaming device which can be modified to pay only        top jackpot payouts is disclosed in U.S. application Ser. No.        10/419,304, filed Apr. 18, 2003. entitled “GAMING DEVICE METHODS        AND APPARATUS EMPLOYING MODIFIED PAYOUTS”, the entirety of which        is incorporated by reference herein for all purposes.    -   (vi) Features that enhance play of a gaming device by modifying        the rate at which outcomes are resolved based on actions of the        player. A feature affecting the operation of a gaming device by        decreasing the time it takes for the reels of the gaming device        to resolve to an outcome when player impatience is detected is        disclosed in U.S. application Ser. No. 10/417,436, filed Apr.        16, 2003, entitled “METHOD AND APPARATUS FOR OPTIMIZING THE RATE        OF PLAY OF A GAMING DEVICE”, the entirety of which is        incorporated by reference herein for all purposes.    -   (vii) Features that enhance the operation of a gaming device by        allowing a player to modify at least one element of a gaming        device (or of a game). A feature enhancing the operation of a        gaming device by allowing a player to modify at least one        element of the gaming device in accordance with the present        invention is disclosed in U.S. application Ser. No. 10/361,201,        filed Feb. 7, 2003, entitled “GAMING DEVICE AND METHOD OF        OPERATION THEREOF”, the entirety of which is incorporated by        reference herein for all purposes.    -   (viii) Features that enhance the operation of a gaming device by        providing a tour or other demonstration of bonus round        functionality (e.g. instructions, strategies, payout amounts) on        the gaming device, such as are disclosed in U.S. application        Ser. No. 10/414,511 filed Apr. 15, 2003, entitled “METHOD AND        APPARATUS FOR BONUS ROUND PLAY”, the entirety of which is        incorporated by reference herein for all purposes.    -   (ix) Features that affect operation of a game and/or a gaming        device, such as by having a virtual assistant (represented by an        animated game character appearing on the screen of the gaming        device) reveal an alternate outcome in a reeled slot machine        game, as are disclosed in U.S. application Ser. No. 10/328,116,        filed Dec. 20, 2002, entitled “METHOD AND APPARATUS FOR        OUTPUTTING OUTCOMES OF A GAMING DEVICE”, the entirety of which        is incorporated by reference herein for all purposes.    -   (x) Features providing enhancements of gaming devices such as        allowing linked play via gaming and other devices, such as are        disclosed in U.S. application Ser. No. 10/254,831, filed Sep.        25, 2002, entitled “METHOD AND APPARATUS FOR LINKED PLAY        GAMING”, the entirety of which is incorporated by reference        herein for all purposes.    -   (xi) Features that affect the operation of a nearby gaming        device, such as an embodiment in which the gaming devices        surrounding a gaming device that has recently been achieving a        lot of high paying outcomes have their own payout levels        temporarily increased, such as are disclosed in U.S. application        Ser. No. 10/007,874, filed Nov. 12, 2001, entitled “ELECTRONIC        AMUSEMENT DEVICE AND METHOD FOR PROPAGATING A PERFORMANCE        ADJUSTMENT SIGNAL”, the entirety of which is incorporated by        reference herein for all purposes.    -   (xii) Features that permit players access to services and/or        content at the gaming device (such as a gaming device that        allows players to make long distance phone calls provided that        they maintain a predetermined rate of play) such as are        disclosed in U.S. application Ser. No. 10/322,107, filed Dec.        18, 2002, entitled “FREE LONG DISTANCE CALLS ON SLOT MACHINES”,        the entirety of which is incorporated by reference herein for        all purposes.

Other appropriate features will be recognized by one of ordinary skillin the art after reading the present application. Note that a variety ofdifferent types of features are possible, including, without limitation:(i) features that are only available for one game, (ii) features thatare available for a plurality of games, (iii) features that are onlyavailable for use on one gaming device, (iv) features that are availablefor use on a plurality of gaming devices, (v) features that areavailable for use by one player, and (vi) features that are availablefor use by a plurality of players. For example, a feature may beavailable on slot machines and pachinko machines, but not on video pokermachines or video blackjack machines. In another example, a feature fora bonus mode may work on all types of machines, but be best suited forcard games like video blackjack and video poker.

According to some embodiments, multiple features may be enabled and/oractive simultaneously on a single game or gaming device. For example, aplayer may play a video poker machine using a “Group Jackpot” featureand a “Virtual Assistant” feature. According to other embodiments, afirst feature may not be compatible with a second feature. For example,it may not be possible for a first feature and a second feature to beactive concurrently (e.g., if they provide for mutually exclusive payoutmodes). Therefore, players may be prevented from using these featuressimultaneously.

According to one or more embodiments of the present invention, a featureof a game or of a gaming device may be enabled for use on one or moregaming devices. According to some embodiments of the present invention,enabling a feature for use on a gaming device includes making thefeature active on the gaming device (i.e. affecting operations of a gameand/or of the gaming device in accordance with the feature).

According to other embodiments of the present invention, if a feature isenabled for use on a gaming device, it may be either active or inactiveon the gaming device. In other words, a feature may be made available(e.g., by a server computer) for use on the gaming device, but thefeature may or may not actually be in use (e.g., it may or may not beaffecting play at the gaming device). For example, the feature may beenabled, but a player may not be using the gaming device. In anotherexample, the feature may be enabled on a gaming device that is beingoperated by a player, but the player is playing a game that the featuredoes not affect. In another example, the feature may be enabled on agaming device that is being operated by a player, but the feature hasnot been activated by the player, a server computer, or the gamingdevice to affect play.

In one or more embodiments of the present invention, enabling a featurefor use on a gaming device means that the feature may be offered to aplayer at the gaming device.

In some embodiments of the present invention, enabling a feature for useon a gaming device may comprise indicating that the feature is allowedto be used on the gaming device, regardless of whether it is actuallyever used. In some embodiments, an indication that a feature ispermitted for use on one or more gaming devices and/or for use with oneor more games may be stored in a data structure on a computer-readablemedium (e.g., in a gaming device database).

In some embodiments, enabling a feature on a gaming device comprisesproviding appropriate instructions (e.g., in computer program code) tothe gaming device that the gaming device may execute in order to providethe feature.

In some embodiments, if a feature is enabled, then a player is able touse the feature when playing a game on a gaming device. For example, aplayer may play a slot machine game in accordance with a particularfeature if the feature is enabled for use on the slot machine.

According to some embodiments, a player may activate and/or deactivateone or more features on a gaming device. In some embodiments, a playermay request that one or more features be made active on a gaming device.For example, the player may select an inactive feature (e.g. from aplurality of inactive features displayed to the player), making thefeature active. In some embodiments, the player may select the featureto activate or deactivate in response to a displayed indication of thefeature, such as a menu list of features available on the gaming device.According to some embodiments, a player may be able to select onlyfeatures that are enabled for a game or gaming device; in otherembodiments, the player may be able to select to activate a feature thatis not yet enabled.

Apparatus and methods which, among other things, permits and enablesvarious ways of displaying indications of available features to playersand of allowing players to select features for play of a gaming device,and which are appropriate for use in accordance with the presentinvention are disclosed in pending U.S. patent application Ser. No.10/419,478, filed Apr. 18, 2003, entitled “METHOD AND APPARATUS FORENABLING A PLAYER TO SELECT FEATURES ON A GAMING DEVICE”, the entiretyof which is incorporated herein by reference as part of the presentdisclosure. That application, for example, provides for a user interfaceenabling a player at a gaming device to activate quickly and easily thefeatures that he would like to use on the gaming device.

In one or more embodiments of the present invention, the player mayreceive an offer to enable and/or use one or more features. In someembodiments, a player may be offered the use of one or more features inexchange for a fee or other consideration. In other embodiments, aplayer may pay a fee or provide other consideration in order to disableor deactivate a feature. Alternatively, a player may be able to activateand/or deactivate a feature on a gaming device free of charge.

A cost or fee associated with the use of a feature by a player may bebased on many factors, including, but not limited to:

-   -   (i) How long a player uses a feature. For example, a player may        be charged $0.05 per minute while he uses an “Automatic Play”        feature on a slot machine.    -   (ii) How many times a player uses a feature. For example, a        player may pay $0.50 each time he gets a winning outcome using a        “Virtual Assistant” feature.    -   (iii) One or more benefits (e.g., payouts) received by a player        while using a feature. For example, a player may pay a tax of 5%        of the value of his prizes won while a feature was active, in        exchange for being able to use the feature on a gaming device.

According to some alternative embodiments, a player may not be able toselect what feature(s) are in use for a game or gaming device. Forexample, the operation of a game or gaming device may be affected by afixed set of one or more features (e.g., as established by a casino). Inanother example, once a feature is enabled it is put in use, and aplayer and/or a gaming device may not be able to deactivate the feature.

According to other embodiments, a gaming device or a server computer maymake a feature active on the gaming device. For example, a casino mayactivate a gaming device enhancement that provides for the occasionaldisplaying of offers for various products and services to players at agaming device. In another example, a casino may activate a gameenhancement that provides for the displaying of offers for products andservices based on certain game events (e.g., upon the awarding of apayout exceeding a predetermined threshold).

According to one or more embodiments of the present invention, if two ormore features are incompatible with one another or otherwise unsuitablefor concurrent activation, then a player, a gaming device, or a computer(e.g., a slot server) may be prevented from selecting or otherwiseactivating one or more of the incompatible features. Information aboutthe compatibility of a feature with one or more other features may bestored in a data structure (e.g. a feature database).

In one or more embodiments of the present invention, activating afeature on a gaming device includes one or more of, without limitation:

-   -   (i) enabling a player to play a gaming device using the feature;    -   (ii) enabling a player to play a gaming device in accordance        with the feature;    -   (iii) enabling a player to play a game on the gaming device        using the feature;    -   (iv) enabling a player to play a game in accordance with the        feature (e.g., with modified outcomes, with a modified payout        table);    -   (v) enabling the player to access a service in accordance with        the feature (e.g. for a feature that enhances the operation of a        gaming device to provide access to a service);    -   (vi) enabling the player to receive a product/service in        accordance with the feature;    -   (vii) enabling the player to access content in accordance with        the feature;    -   (viii) enabling the player to achieve a modified outcome in        accordance with the feature;    -   (ix) enabling the player to play the gaming device in accordance        with modified outcome probabilities;    -   (x) enabling the player to achieve a modified payout amount in        accordance with the feature; and    -   (xi) enabling the player to customize a game in accordance with        the feature.

The scope of the present invention and embodiments thereof may beunderstood more fully with reference to the following figures. Theleftmost (i.e. the most significant) digit(s) of a reference numeraltypically identifies the figure in which the reference numeral firstappears. It should be noted that the embodiments described withreference to the following figures are presented for illustrativepurposes only and are not meant to be limiting in any sense. Further,although particular features of the present invention may be describedwith reference to one or more particular embodiments or figures, itshould be understood that such features are not limited to usage in theone or more particular embodiments or figures with reference to whichthey are described.

Embodiments of the present invention will first be introduced by meansof flowcharts that illustrate some basic processes that may be utilizedby an entity practicing the present invention. The system infrastructurewill then be described with reference to block diagrams of exemplarysystems and devices that may be utilized by an entity practicing thepresent invention. Exemplary data structures illustrating tables thatmay be used when practicing some embodiments of the present inventionwill then be described, along with corresponding flowcharts thatillustrate exemplary processes that utilize the exemplary tables.

Referring now to FIG. 1A, a flowchart illustrates a process 100A that isillustrative of some embodiments of the present invention. The process100A includes a method for determining whether a feature should beenabled on a gaming device. The process 100A, and all other processesdescribed herein unless expressly specified otherwise, may be performedby a gaming device, a computer (e.g., a slot server) in communicationwith the gaming device, a peripheral device in communication with agaming device, a peripheral device server and/or a combination thereof.Each of these devices is described in detail below. Further, the process100A, and all other processes described herein unless expresslyspecified otherwise, may include steps in addition to those expresslydepicted in the Figures or described in the specification withoutdeparting from the spirit and scope of the present invention. Similarly,the steps of process 100A and any other process described herein, unlessexpressly specified otherwise, may be performed in any practicable orderincluding orders other than those depicted in the Figures or describedin the specification, as appropriate.

Referring to step 105, a feature is determined. In step 110, the entitydetermines whether the determined feature should be enabled on at leastone gaming device. In some embodiments the determination may comprisedetermining whether or not to enable a disabled feature. In otherembodiments, the feature may already be enabled on one or more of the atleast one gaming device, and the determination may thus comprisedetermining whether or not to keep the feature enabled (e.g., on thosegaming devices on which it is already enabled).

In some embodiments, determining whether a feature should be enabled maybe based on a condition. FIG. 1D depicts a process, consistent with oneor more embodiments of the present invention, in which a feature may beenabled based on whether a predetermined condition is satisfied.

It will be readily understood that determining whether a feature shouldbe enabled may comprise determining whether the feature should bedisabled. In some embodiments, determining whether a feature should beenabled may be based on a measure of performance of the feature. FIG. 1Bdepicts a process, consistent with one or more embodiments of thepresent invention, in which a measure of performance of a feature isdetermined and the feature may be disabled based on the measure ofperformance. Note that FIG. 1B and FIG. 1D illustrate only two possiblemethods for determining whether to enable (or whether to disable) afeature for use on a gaming device. Many other methods are possible.

A rule-based system appropriate for use in accordance with the presentinvention is disclosed in pending U.S. patent application Ser. No.09/603,677, filed Jun. 26, 2000, entitled “METHOD AND APPARATUS FORSELECTING A SUPPLEMENTAL PRODUCT TO OFFER FOR SALE DURING ATRANSACTION”, the entirety of which is incorporated herein by referenceas part of the present disclosure.

According to one or more embodiments of the present invention, a featuremay be enabled or disabled for use on one or more gaming devices basedon one or more rules. In some embodiments, such one or more rules may beassociated with, for example, a predetermined condition, as described inFIG. 1D. In another embodiment, such one or more rules may be associatedwith the player who is operating a gaming device, with the owner of thegaming device, or with a provider of a feature. In yet anotherembodiment, the one or more rules may be associated with the gamingdevice that a player is operating (e.g., the same one or more rules isused to determine whether the feature should be enabled regardless ofwho the player is or what games may be available for use on the gamingdevice).

In yet another embodiment, the one or more rules may be selectedrandomly. In one exemplary method of selecting a rule randomly, a randomnumber generated by a random number generator may be determined and atable of rules may be accessed in which each rule corresponds to arespective random number, or range of random numbers that may begenerated by a random number generator.

As is known in the art, a rules-based system may be modified by anadaptive system in order to increase the performance of the rules-basedsystem. An adaptive system which, among other things, may create its ownrules and/or modifies rules in accordance with desired performance, andwhich is appropriate for use in accordance with the present invention isdisclosed in pending U.S. patent application Ser. No. 09/993,228, filedNov. 14, 2001, entitled “METHOD AND APPARATUS FOR DYNAMIC RULE AND/OROFFER GENERATION”, the entirety of which is incorporated herein byreference as part of the present disclosure. That application disclosesan apparatus and method, which permits and enables rules-basedapplications (such as a system that provides customers withdynamically-priced upsell offers) to become “self improving” and thusincrease performance over time.

Such an adaptive system can adjust at least some of the rules inaccordance with at least one measure of performance of one or morefeatures. For example, an adaptive system can modify rules such thatfeatures that have previously proven popular among players of slotmachines after they receive a payout of over ten coins (e.g., asindicated by the number of times players have selected the featurewithin five minutes after receiving the payout) are made the subject ofexplicit offers to players at the time they receive such a payout. Inanother example, an adaptive system can modify rules such that featuresthat have previously tended to generate less revenue on video pokermachines during certain times of the day are disabled during thosetimes. In yet another example, an adaptive system can modify rules suchthat when the theoretical win per minute of a group of slot machines haspreviously increased more since a first feature was enabled on the slotmachines than since a second feature was enabled on the slot machines,the second feature is never enabled while that first feature is enabled.Various other types of measures of performance are described herein, andmay be used in accordance with one or more embodiments of the presentinvention to provide for an adaptive rules-based system for determiningwhether one or more features should be enabled or disabled.

By allowing for the adjustment of one or more rules based on one or moremeasures of performance, some embodiments of the present invention mayimprove the profitability of gaming devices over time. In someembodiments of the present invention, as discussed herein, an operatorof gaming devices may make payment to a provider of a feature based onusage of the feature. Accordingly, by making improvements to the ruleseffectively governing which features should be enabled or disabled invarious circumstances, based on one or more measures of performance, theoperator may reduce the enablement and/or usage of an under performingfeature, thereby potentially reducing the amount owed to the feature'sprovider.

Some adjustments of the rules may be based on factors other than, or inaddition to, one or more measures of performance. As discussed above, arule for determining whether a feature should be enabled may be selectedor generated at random from a table of rules. The effectiveness of therandomly-selected rule may then be evaluated in accordance with one ormore measures of performance, further assisting the rule-based system inadapting to improve the performance of the system.

Referring again to process 100A (FIG. 1A), if the feature should beenabled, in step 115 the feature is enabled on the at least one gamingdevice. In some embodiments, enabling the feature may comprise storingan indication in a database (e.g., a software flag) and/or transmittinga signal to a gaming device or peripheral device. If the feature isalready enabled, in some embodiments enabling the feature may compriseany operations necessary to keep the feature enabled, or to extend aperiod of time for which the feature is to be enabled.

Referring to step 120, if the feature should not be enabled, the featureis disabled on the at least one gaming device. It will be understoodthat in some embodiments disabling a feature may comprise one or moreoperations to disable a feature that is enabled, or may comprise anyoperations necessary to keep a feature disabled (e.g., if it is alreadydisabled).

As depicted in FIG. 1A, in some optional embodiments some steps of theprocess 100A may be iterative. For example, after step 115 and/or afterstep 120, operation of the process may return (e.g., after a period oftime, in response to a signal) to step 110 for determining whether thefeature should be enabled. In this way, an entity may monitor and/orre-evaluate (e.g., periodically, intermittently, or at any time) whetherthe feature should be enabled on the at least one gaming device.

Referring now to FIG. 1B, a flowchart illustrates a process 100B that isconsistent with one or more embodiments of the present invention. Theprocess 100B is a method for disabling a feature based on theperformance of an enabled feature. Referring to step 125, a feature isenabled for use on one or more gaming devices. In some embodiments, thefeature may be enabled automatically based on any one or more of variouspredetermined conditions (e.g., if a player has wagered more than apredetermined amount within ten minutes, or in response to a receivedsignal). In other embodiments, the feature may be enabled manually by oron behalf of an operator of a gaming device (e.g., by a casinorepresentative operating a computer).

In step 130, a measure of performance of the feature on the at least onegaming device is determined. In some embodiments, determining a measureof performance of a feature comprises determining a measure of usage ofthe feature on a gaming device. FIG. 1D depicts a process, consistentwith one or more embodiments of the present invention, in which ameasure of usage of a feature is determined. Note that FIG. 1Dillustrates only one possible method for determining a measure ofperformance. Other methods will be described herein, and still otherswill be apparent to those skilled in the art upon reading the presentdisclosure.

Referring again to process 100B (FIG. 1B), in step 135 it is determinedwhether the enabled feature should be disabled based on the measure ofperformance. If the feature should not be disabled, the process ends;otherwise, in step 140 the feature is disabled and the process ends.

Referring now to FIG. 1C, a flowchart illustrates a process 100C that isconsistent with one or more embodiments of the present invention. Theprocess 100C is a method for determining a payment due to a provider ofa feature. Referring to step 145, a measure of performance of a featureon at least one gaming device is determined. In some embodiments,determining the measure of performance comprises determining a measureof usage of a feature on a gaming device (e.g., an amount of coin-in, anamount of time that the feature was active on the gaming device, atransaction volume for accepted product/service offers that wereprovided to players in accordance with the feature).

In step 150, a payment due to a provider of the feature is determined,based on the measure of performance of the feature. In some embodiments,determining a payment comprises determining a payment rate associatedwith a feature. FIG. 1D depicts a process, consistent with one or moreembodiments of the present invention, in which a measure of usage of afeature and a payment rate for a feature are determined, and a paymentis determined based on the measure of usage and the payment rate.

Note that FIG. 1D illustrates only one possible method for determining apayment due to a provider of a feature. Some embodiments may includeidentifying one or more parties to whom payment is due, including one ormore providers of the feature. Providers who may be owed payment (e.g.based on usage of the feature) include manufacturers of gaming devicesor game manufacturers, holders of intellectual property related to afeature (e.g. holders of patents, trademarks, copyrights, or tradesecrets), and licensors of a feature. Payment may be based on licensing,leasing, renting, or feature usage agreements between a provider (orproviders) of a feature, game, or gaming device, and a casino or otherowner, lessee, or operator of a gaming device. For example, a casino mayagree to pay a provider of a feature 10% of the net profits obtained asa result of using a feature on a gaming device. In another example, agaming manufacturer may be entitled to 1% of revenue generated at agaming device while a feature is in use. In yet another example, aproprietor of a feature may be owed payment of $0.50 each time a featureis used on a gaming device. Other methods for determining payment willbe described herein, and still others may be apparent to those skilledin the art upon reading the present disclosure.

Referring now to FIG. 1D, a flowchart illustrates a process 100D that isconsistent with one or more embodiments of the present invention. Theprocess 100D is a method for enabling a feature and determining apayment. Referring to step 155, a feature is determined. In step 160 agaming device is determined. In step 165 it is determined whether apredetermined condition has been satisfied. The predetermined condition,in the context of process 100D, is a condition that must be satisfied inorder for the feature determined in step 155 to be enabled on the gamingdevice determined in step 160.

Some of the various types of information on which predeterminedconditions may be based, and which may be used to determine whether apredetermined condition is satisfied, are discussed herein and withreference to the accompanying figures. In some embodiments, for example,a predetermined condition will be related to information about thefeature whose enablement is being determined. In other embodiments, thepredetermined condition may be related to information about one or moreother features. For example, a condition for enabling one feature on agaming device may be satisfied if another feature has been used at thatgaming device for more than a predetermined period of time.

Note that more than one predetermined condition may be available and/ornecessary for satisfaction. In such embodiments, the process 100D maycontinue to step 170 if any one of a plurality of predeterminedconditions is satisfied. Alternatively, a combination of predeterminedconditions may each need to be satisfied in order for the process 100Dto continue to step 170.

If it is determined, in step 165, that the predetermined condition hasnot been satisfied, the process 100D ends. If it is determined, on theother hand, that the condition has been satisfied, then the process 100Dcontinues to step 170, in which the feature is enabled for use on thedetermined gaming device. In step 175, a measure of usage of the featureon the gaming device is determined. Various measures of usage aredescribed herein. In some embodiments, for example, the measure of usageis an amount of coin-in at the gaming device while the feature is inuse.

In step 180, a payment rate for the feature is determined. In step 185 apayment is determined based on the measure of usage of the feature andthe payment rate. For example, a rate of $0.02 per minute the feature isactive is determined (e.g., by accessing a payment database entrycorresponding to the feature), and it is determined that the feature wasactive for a total of 2,034 minutes. Accordingly, a payment amount of$40.68 would be determined.

In step 190 the payment is submitted to a provider of the feature. Insome embodiments, as described below, process 100D may further oralternatively include additional steps such as encoding the datarepresentative of “the feature was active for 2,034 minutes” using anencryption key and outputting a code for transmission to the featureprovider. For example, along with the $40.68, a twelve digit codeencrypted using a public key and representative of 2,034 minutes may beprovided to the licensor of the feature. Using the code, the licensormay then verify that the payment amount was reported accurately bydecrypting the code using a private key. Payment may be submitted to aparty in any manner well known in the art (e.g., by initiating anelectronic transfer of funds), and need not be described in furtherdetail. Process 100D terminates after submitting payment and/orproviding the code to the licensor.

Applicants have recognized that the accumulation, storing, encrypting,and/or analysis of various types of information may be helpful in themanagement of features on gaming devices. Many types of information arediscussed herein. Some types of information may be helpful, for example,in determining whether a feature should be enabled or disabled. Sometypes of information may be useful, for example, in determining apayment due to a provider of a feature. Some types of information, forexample, may be useful for both determining whether a feature should beenabled or disabled and for determining a payment due to a provider of afeature. Some types of information may be useful in establishing rulesin a rules-based system, and/or for establishing predeterminedconditions.

Examples of types of information that may be helpful in managingfeatures for use on one or more gaming devices and/or with one or moregames include, but are not limited to:

-   -   (i) information about performance of one or more features;    -   (ii) information about usage of one or more features;    -   (iii) information about usage of one or more gaming devices;    -   (iv) information about profitability of one or more features;    -   (v) information about profitability of one or more gaming        devices;    -   (vi) information about players, including information about the        gambling activity of players;    -   (vii) information about offers provided to players in accordance        with one or more features;    -   (viii) indications (e.g., signals) from various parties;    -   (ix) information about a casino or other establishment;    -   (x) information about one or more games;    -   (xi) information about one or more providers of features;    -   (xii) time-related conditions;    -   (xiii) authorization codes; and    -   (xiv) random numbers.

Other appropriate categories or types of information will be recognizedby one of ordinary skill in the art after reading the presentapplication. The types of information described herein are categorizedfor illustrative purposes only. Note that some information consistentwith one or more embodiments of the present invention may reasonably beconsidered as related to or falling within two, more than two, or noneof the categories of information described herein. Also, althoughinformation may be described as being related to a single entity (e.g.,a player, a gaming device) for illustrative purposes only, one skilledin the art will understand that similar information related to aplurality of such entities (e.g., an aggregate revenue generated on allgaming devices, an average per gaming device) may also be used inaccordance with one or more embodiments of the present invention.

A measure of performance, as used herein unless expressly indicatedotherwise, may refer to a measure of performance of a feature and/or ofa gaming device, and may include, but is not limited to, (i) one or moremeasures of usage of features and/or gaming devices; (ii) one or moremeasures of profitability of features and/or gaming devices, and/or(iii) variances in any such measures that may be correlated to the useor non-use of one or more features on a gaming device.

In some embodiments, a measure of performance may comprise an indicationof a change in a particular measure (e.g., of usage, of profitability)related to a feature (or to a gaming device). For example, a measure ofperformance of a feature may be the determined increase in the number ofplayers using a gaming device at which the feature is enabled, or anincrease in the average amount that players wager at a gaming device onwhich the feature is enabled. In another example, an increase in thetheoretical win per minute of a gaming device, during a period thatstarted when a feature was enabled at the gaming device, may be a usefulindicator in determining whether the feature should be enabled ordisabled on the gaming device, as well as for determining whether thefeature should be enabled or disabled on other gaming devices. Forexample, a condition may be established that if the increase is greaterthan a predetermined value, then the feature should be automaticallyenabled on other gaming devices of the same type.

Measures of usage, performance, and profitability are also convenientfor determining payment due to providers of features. In anotherexample, some features may enhance operation of gaming devices or ofgames in order to promote the fulfillment of certain types of goals,such as teaching players how to use a certain type of gaming device, orencouraging players to play gaming devices more quickly. Measures ofperformance of such features may thus include information related to thedesired goals (e.g., an average wager size, an average rate of play).

Some examples of information that may facilitate the management ofvarious features for use on one or more gaming devices (e.g., indetermining whether a feature should be enabled on a gaming device)include, but are not limited to:

-   -   (i) An amount of revenue generated while a feature is in use;    -   (ii) An average amount wagered by a player (or players) while a        feature is in use;    -   (iii) An average rate of play when a player is using a feature;    -   (iv) An average session theoretical win when a player is using a        feature;    -   (v) A number of customer service complaints relating to a        feature;    -   (vi) An average duration of a gaming session when a player is        using a feature;    -   (vii) A number of machines at which a feature is active;    -   (viii) A percentage amount of machines at which a feature is        active;    -   (ix) A number of times that a feature is used (e.g., within a        period of time);    -   (x) An average number of times that a feature is used by a        player;    -   (xi) A period of time that a feature is in use (e.g., in minutes        or hours);    -   (xii) A period of time that one or more gaming devices are in        use;    -   (xiii) A percentage amount of all gaming devices that are gaming        devices on which a feature is in use;    -   (xiv) Which game(s) a feature is used with;    -   (xv) Which gaming device(s) (e.g., types of gaming devices) a        feature is used with;    -   (xvi) What types of players use a feature (e.g., new players,        old players, “high rollers”);    -   (xvii) Information about features that are used concurrently        with at least one other feature;    -   (xviii) A time of day when a feature is used (e.g., during peak        hours, during the middle of the night);    -   (xix) A profit of a gaming device while a feature was in use;    -   (xx) An amount of revenue resulting from use of the feature;    -   (xxi) A profit from use of the feature (e.g., profit earned from        accepted offers);    -   (xxii) A cost resulting from use of a feature (e.g., a cost        associated with providing a service in accordance with a        feature);    -   (xxiii) An increase (or decrease) in payout percentage (e.g., at        one or more gaming devices;    -   (xxiv) An increase (or decrease) in theoretical win (e.g. at one        or more gaming devices)    -   (xxv) An increase (or decrease) in an amount of revenue        generated at an ancillary merchant, establishment or enterprise        related to an offer (e.g., revenue generated at a restaurant        sponsoring a dinner offer that is provided in accordance with a        feature)    -   (xxvi) A value of a benefit (e.g., money) paid to a player        (e.g., money paid to a player by sponsors, such as if a player        performs one or more value-added activities);    -   (xxvii) An amount of revenue generated at one or more gaming        devices near a gaming device at which a feature is used (e.g. if        a features makes play so entertaining that it makes players move        to one area of the casino);    -   (xxviii) A number or value of comps received by a player (e.g.,        playing a feature-enabled gaming device);    -   (xxix) A percentage of funds stored with a server (e.g. due to        interest);    -   (xxx) A player's rate of play while a feature is in use;    -   (xxxi) An increase or decrease in a player's rate of play (e.g.,        comparing play with a feature enabled and play without the        feature enabled);    -   (xxxii) A number of offers accepted or rejected by a player        (e.g., for a feature that makes offers to a player);    -   (xxxiii) A percentage of offers that are rejected/that are        accepted;    -   (xxxiv) An increase or decrease in the amount of coin-in by a        player (e.g. comparing play with a feature enabled and play        without the feature enabled);    -   (xxxv) An increase or decrease in the (average) session length        of a player (e.g. comparing feature-enabled play and        non-enhanced play);    -   (xxxvi) An increase or decrease in the percentage of time a        player spends gambling during a casino visit (e.g., comparing        feature-enabled play and non-enhanced play);    -   (xxxvii) Whether a player signs up for a player tracking card;    -   (xxxviii) A number of players who sign up for player tracking        cards;    -   (xxxix) How often a feature is used (e.g., whether the number of        times a feature is used on a gaming device (or gaming devices)        each day is greater than a predetermined number of times);    -   (xl) A period of time for which a feature is used by a player        (or players) (e.g., for determining whether the period of time        that a player used a feature was less than five minutes, or        whether the average period of time that players use a feature is        less than two hours);    -   (xli) What type(s) of games the feature is used with (e.g., for        determining whether the feature is used with games on bonus        round slot machines, or with video poker machines);    -   (xlii) What type(s) of gaming devices the feature is used with        (e.g., for determining whether the feature is used on machines        in the smoking section);    -   (xliii) What type(s) of players use the feature (e.g., for        determining whether a predetermined minimum number of novice        players have used the feature); and    -   (xliv) A number of different players who have used the feature        (e.g., for determining whether a predetermined minimum number of        unique players have used the feature).

Other types of information useful in managing features will berecognized by one of ordinary skill in the art after reading the presentapplication.

Although measures related to usage of a feature (e.g. informationrelated to behavior of players at a gaming device while a feature wasactually active or in use) are discussed frequently herein as usefulmeasures of performance of a feature, it will be understood that auseful measure of performance may be related to activity at a gamingdevice while a feature is merely enabled for use on the gaming device,regardless of whether the feature is ever used or activated by a player.For example, a player may be attracted to a gaming device at which aparticular feature is enabled for use (and may as a result spend longerplaying the gaming device), simply because the particular feature isavailable to the player, or may be offered to or activated for theplayer, even if the player does not use the feature most of the time oreven at all. In other words, some players may choose to play a gamingdevice at which particular features are enabled over another gamingdevice lacking the features, even if the player does not take advantageof the features' enhancements.

Referring now to FIG. 2A, a block diagram of a system 200 according toat least some embodiments of the present invention includes a computer210 (e.g., a slot server of a casino) that is in communication, via acommunications network 220, with one or more gaming devices 230 (e.g.,slot machines, video poker machines). The computer 210 may communicatewith the devices 230 directly or indirectly, via a wired or wirelessmedium such as the Internet, LAN, WAN or Ethernet, Token Ring, or viaany appropriate communications means or combination of communicationsmeans. Each of the devices 230 may comprise computers, such as thosebased on the INTEL® PENTIUM® processor, that are adapted to communicatewith the computer 210. Any number and type of devices 230 may be incommunication with the computer 210.

Communication between the devices 230 and the computer 210, and amongthe devices 230, may be direct or indirect, such as over the Internetthrough a Web site maintained by computer 210 on a remote server or overan on-line data network including commercial on-line service providers,bulletin board systems and the like. In yet other embodiments, thedevices 230 may communicate with one another and/or computer 210 overRF, cable TV, satellite links and the like.

Some, but not all, possible communication networks that may comprisenetwork 220 or be otherwise part of system 200 include: a local areanetwork (LAN), a wide area network (WAN), the Internet, a telephoneline, a cable line, a radio channel, an optical communications line, asatellite communications link. Possible communications protocols thatmay be part of system 200 include:

Ethernet (or IEEE 802.3), SAP, ATP, Bluetooth™, and TCP/IP.Communication may be encrypted to ensure privacy and prevent fraud inany of a variety of ways well known in the art.

Those skilled in the art will understand that devices in communicationwith each other need not be continually transmitting to each other. Onthe contrary, such devices need only transmit to each other asnecessary, and may actually refrain from exchanging data most of thetime. For example, a device in communication with another device via theInternet may not transmit data to the other device for weeks at a time.

In some embodiments, the computer 210 may not be necessary and/orpreferred. For example, the present invention may, in one or moreembodiments, be practiced on a stand-alone gaming device 230 and/or agaming device 230 in communication only with one or more other gamingdevices 230. In such an embodiment, any functions described as performedby the computer 210 or data described as stored on the computer 210 mayinstead be performed by or stored on one or more gaming devices 230.

Referring now to FIG. 2B, a block diagram of another system 250according to at least some embodiments of the present invention includesa computer 210 (e.g., a slot server of a casino) that is incommunication, via a communications network 220, with one or more gamingdevices 230 (e.g. slot machines, video poker machines). A differencebetween system 200 (FIG. 2A) and system 250 (FIG. 2B) is that in system250 at least one gaming device 230 is also in communication with one ormore peripheral devices 240. A peripheral device 240 may, in turn, be incommunication with a peripheral device server 245 and, in someembodiments, with computer 210. In one or more embodiments theperipheral device server 245 may be in communication with one or moregaming devices 240 and/or computer 210.

The computer 210 may communicate with the devices 230 and devices 240directly or indirectly, via a wired or wireless medium such as theInternet, LAN, WAN or Ethernet, Token Ring, or via any appropriatecommunications means or combination of communications means. Forexample, the computer 210 may communicate directly with one of thegaming devices 230 (e.g., via a LAN) and indirectly (e.g., via a gamingdevice 230) with a peripheral device 240. In another example, thecomputer 210 may communicate with one of the gaming devices 230 via aLAN and with another of the gaming devices 230 via the Internet (e.g.,if the particular gaming device comprises a personal computer incommunication with an online casino).

Each of the devices 230 and the devices 240 may comprise computers, suchas those based on the INTEL® PENTIUM® processor, that are adapted tocommunicate with the computer 210. Further, each of the devices 230 maycomprise a gaming device such as a mechanical or electronic slotmachine, a video poker machine, a video blackjack machine, a video kenomachine, a pachinko machine, a video roulette machine, and/or a lotteryterminal. Further yet, each of the devices 240 may comprise an externalor internal module associated with one or more of the gaming devices 230that is capable of communicating with one or more of the gaming devices230 and of directing the one or more gaming devices 230 to perform oneor more functions. Any number of devices 230 may be in communicationwith the computer 210. Any number and type of peripheral devices 240 maybe in communication with a gaming device 230, peripheral device server245 and computer 210.

Communication between the devices 230 and the computer 210, between thedevices 230 and devices 240, between peripheral device server 245 andthe devices 240 and/or the devices 230, between the peripheral deviceserver 245 and computer 210, among the devices 230, and among thedevices 240 may be direct or indirect, such as over the Internet througha Web site maintained by computer 210 on a remote server or over anon-line data network including commercial on-line service providers,bulletin board systems and the like. In yet other embodiments, any andall of the devices of system 250 (i.e., the devices 230, the devices240, the computer 210, and the peripheral device server 245) maycommunicate with one another over RF, cable TV, satellite links and thelike.

Some, but not all, possible communication networks that may comprisenetwork 220 or otherwise be part of system 250 include: a local areanetwork (LAN), a wide area network (WAN), the Internet, a telephoneline, a cable line, a radio channel, an optical communications line, asatellite communications link. Possible communications protocols thatmay be part of system 250 include: Ethernet (or IEEE 802.3), SAP, ATP,Bluetooth™, and TCP/IP. Communication may be encrypted to ensure privacyand prevent fraud in any of a variety of ways well known in the art.

In some embodiments, the computer 210 may not be necessary and/orpreferred. For example, the present invention may, in one or moreembodiments, be practiced on a stand-alone gaming device 230, one ormore gaming devices in communication with one or more peripheral devices240, one or more gaming devices in communication with peripheral deviceserver 245, one or more peripheral devices 240 in communication withperipheral device server 245, and/or a gaming device 230 incommunication only with one or more other gaming devices 230. In such anembodiment, any functions described as performed by the computer 210 ordata described as stored in a memory of the computer 210 may instead beperformed by or stored on one or more gaming devices 230, one or moreperipheral devices 240, and/or peripheral device server 245.

Similarly, peripheral device server 245 may not be desired and/or neededin some embodiments of the present invention. In embodiments that do notinvolve peripheral device server 245, any or all of the functionsdescribed herein as being performed by peripheral device server 245 mayinstead be performed by computer 210, one or more gaming devices 230,one or more peripheral devices 240, or a combination thereof. Similarly,in embodiments that do not involve peripheral device server 245 any datadescribed herein as being stored in a memory of peripheral device server245 may instead be stored in a memory of computer 210, one or moregaming devices 230, one or more peripheral devices 240, or a combinationthereof.

Any or all of the gaming devices 230 may, respectively, include or be incommunication with a peripheral device 240. A peripheral device 240 maybe a device that receives information from (and/or transmits informationto) one or more gaming devices 230. For example, a peripheral device 240may be operable to receive information about games being played on agaming device 230, such as the initiation of a game and/or a randomnumber that has been generated for a game, and/or may be operable toreceive information about features enabled or in use on the gamingdevice 230.

In one or more embodiments, one or more such peripheral devices 240 maybe in communication with a peripheral device server 245. This allows theperipheral device server 245 to receive information regarding aplurality of games being played on a plurality of gaming devices 230.The peripheral device server 245, in turn, may be in communication withthe computer 210. It should be understood that any functions describedherein as performed by a peripheral device 240 may also or instead beperformed by the peripheral device server 245. Similarly, any datadescribed herein as being stored on or accessed by a peripheral device240 may also or instead be stored on or accessed by the peripheraldevice server 245.

A peripheral device 240 may be operable to access a database (e.g. ofperipheral device server 245) to provide benefits (e.g., cashless gamingreceipts) based on, for example, an active feature of a gaming device230. A peripheral device 240 may also be operable to access a database(e.g., a feature database, as described in more detail below) todetermine a product/services offer to output on a gaming device (e.g.,in accordance with an active feature).

The peripheral device server 245 may also monitor player gamblinghistory over time by associating gambling behavior with playeridentifiers, such as player tracking card numbers. For example, inembodiments wherein a player selects which feature is to be active, theperipheral device server 245 may track which feature the player haspreviously selected and subsequently use that information to presentother offers for features to the player and/or to output otherinformation to the player. Further, information about the playerobtained or accessed by peripheral device server 245 may be analyzed,e.g., to identify those players that a particular gaming machine owner,operator, or manufacturer finds most desirable. Based upon desiredobjectives, the peripheral device server 245 may direct the appropriateperipheral device 240 to issue customized messages to specific playersthat are relevant to their gambling behaviors.

Information received by a peripheral device 240 from a gaming device 230may include gambling data such as number of games initiated per unit oftime, outcomes displayed for games initiated, payouts corresponding tooutcomes displayed, a credit meter balance of the gaming device, and/ordata associated with the player currently playing the gaming device 230.

The functions described herein as being performed by a peripheral deviceserver 245 and/or a peripheral device 240 may, in one or moreembodiments, be performed by the computer 210 (in lieu of or inconjunction with being performed by a peripheral device server 245and/or a peripheral device 240). Such functions may be performed bycomputer 210 in either system 200 (FIG. 2A) or system 250 (FIG. 2B).

In one or more embodiments, a peripheral device 240 may be useful forimplementing the embodiments of the present invention into the operationof a conventional gaming device. For example, in order to avoid orminimize the necessity of modifying or replacing a program alreadystored in a memory of a conventional gaming device, an external orinternal module that comprises a peripheral device 240 may be insertedin or associated with the gaming device.

Thus, for example, a peripheral device 240 may be utilized to monitorplay of the gaming device and enhance or otherwise affect play inaccordance with one or more active features. In such embodiments thegaming device 230 with which the peripheral device 240 is incommunication with may continue to operate conventionally (e.g. as iffeatures were not active). In such embodiments, for example, if thefeature includes the offering of products or services to players, or thedisplaying of video content, operation of the gaming device 230 maycontinue conventionally. The peripheral device 240, however, may outputone or more offers. The peripheral device 240 may also output messagesto the player (e.g., such as “Would you like to play in Reverse PayoutMode?”). The peripheral device 240 may also provide benefits to a player(e.g., coins, tokens, electronic credits, paper receipts exchangeablefor cash, services, and/or merchandise).

Accordingly, a peripheral device 240 may include (i) a communicationsport (e.g. for communicating with one or more gaming devices 230,peripheral device server 245, another peripheral device 240, and/orcomputer 210); (ii) a display (e.g., for displaying messages and/oroutcomes), (iii) another output means (e.g., a speaker, light, or motiondevice to communicate with a player), and/or (iv) a benefit providingmeans (e.g., a printer and paper dispensing means, a credit meter,and/or a hopper and hopper controller).

In one or more embodiments, the peripheral device may not outputoutcomes and/or messages to a player but may instead direct theprocessor of a gaming device to perform such functions. For example, aprogram stored in a memory of peripheral device 240 may cause aprocessor of a gaming device to perform certain functions. For example,a program stored in a memory of peripheral device 240 may cause aprocessor of a gaming device to provide for enhanced play of the gamingdevice in accordance with one or more enabled features, by modifying howthe gaming device outputs an outcome, determines an outcome, outputs amessage, provides a benefit, and/or displays game information.

Referring now to FIG. 3, illustrated therein is a block diagram of anembodiment 300 of a gaming device. The gaming device 300 may beimplemented as a system controller, a dedicated hardware circuit, anappropriately programmed general-purpose computer, or any otherequivalent electronic, mechanical or electromechanical device. Thegaming device 300 may comprise, for example, a slot machine, a videopoker terminal, a video blackjack terminal, a video keno terminal, avideo lottery terminal, a pachinko machine or a table-top game. Invarious embodiments, a gaming device may comprise, for example, apersonal computer (e.g., which communicates with an online casino Website), a telephone (e.g., to communicate with an automated sports bookthat provides gaming services), or a portable handheld gaming device(e.g. a personal digital assistant or NINTENDO® GAMEBOY®). The gamingdevice 300 may comprise any or all of the gaming devices 230 of system200 (FIG. 2A) or system 250 (FIG. 2B). In some embodiments, a userdevice such as a PDA or cell phone may be used in place of, or inaddition to, some or all of the gaming device 300 components depicted inFIG. 3. Further, a gaming device may comprise a personal computer orother device operable to communicate with an online casino andfacilitate game play at the online casino. In one or more embodiments,the gaming device 300 may comprise a computing device operable toexecute software that simulates play of a reeled slot machine game,video poker game, video blackjack game, video keno game, video roulettegame, or lottery game.

The gaming device 300 comprises a processor 305, such as one or moreINTEL® PENTIUM® processors. The processor 305 is in communication with amemory 310 and a communications port 370 (e.g., for communicating withone or more other devices). The memory 310 may comprise an appropriatecombination of magnetic, optical and/or semiconductor memory, and mayinclude, for example, Random Access Memory (RAM), Read-Only Memory(ROM), a compact disc, tape drive, and/or a hard disk. The memory 310may comprise or include any type of computer-readable medium. Theprocessor 305 and the memory 310 may each be, for example: (i) locatedentirely within a single computer or other device; or (ii) connected toeach other by a remote communication medium, such as a serial portcable, telephone line or radio frequency transceiver. In someembodiments, the gaming device 300 may comprise one or more devices thatare connected to a remote server computer for maintaining databases.

The memory 310 stores a program 315 for controlling the processor 305.The processor 305 performs instructions of the program 315, and therebyoperates in accordance with the present invention, and particularly inaccordance with the methods described in detail herein. The program 315may be stored in a compressed, uncompiled and/or encrypted format. Theprogram 315 furthermore includes program elements that may be necessary,such as an operating system, a database management system and “devicedrivers” for allowing the processor 305 to interface with computerperipheral devices. Appropriate program elements are known to thoseskilled in the art, and need not be described in detail herein.

The term “computer-readable medium” as used herein refers to any mediumthat participates in providing instructions to processor 305 (or anyother processor of a device described herein) for execution. Such amedium may take many forms, including but not limited to, non-volatilemedia, volatile media, and transmission media. Non-volatile mediainclude, for example, optical or magnetic disks, such as memory 310.Volatile media include dynamic random access memory (DRAM), whichtypically constitutes the main memory. Transmission media includecoaxial cables, copper wire and fiber optics, including the wires thatcomprise a system bus coupled to the processor 305. Transmission mediacan also take the form of acoustic, electromagnetic, or light waves,such as those generated during radio frequency (RF), microwave, andinfrared (IR) data communications. Common forms of computer-readablemedia include, for example, a floppy disk, a flexible disk, hard disk,magnetic tape, any other magnetic medium, a CD-ROM, DVD, any otheroptical medium, punch cards, paper tape, any other physical medium withpatterns of holes, a RAM, a PROM, an EPROM, a FLASH-EEPROM, any othermemory chip or cartridge, a carrier wave as described hereinafter, orany other medium from which a computer can read.

Various forms of computer readable media may be involved in carrying oneor more sequences of one or more instructions to processor 305 (or anyother processor of a device described herein) for execution. Forexample, the instructions may initially be borne on a magnetic disk of aremote computer. The remote computer can load the instructions into itsdynamic memory and send the instructions over a telephone line using amodem. A modem local to a gaming device 300 (or, e.g. a computer 210)can receive the data on the telephone line and use an infraredtransmitter to convert the data to an infrared signal. An infrareddetector can receive the data carried in the infrared signal and placethe data on a system bus for processor 305. The system bus carries thedata to main memory, from which processor 200 retrieves and executes theinstructions. The instructions received by main memory may optionally bestored in memory 310 either before or after execution by processor 305.In addition, instructions may be received via communication port 370 aselectrical, electromagnetic or optical signals, which are exemplaryforms of carrier waves that carry data streams representing varioustypes of information. Thus, the gaming device 300 may obtaininstructions in the form of a carrier wave.

According to some embodiments of the present invention, the instructionsof the program 315 may be read into a main memory from anothercomputer-readable medium, such from a ROM to RAM. Execution of sequencesof the instructions in program 315 causes processor 305 to perform theprocess steps described herein. In alternate embodiments, hard-wiredcircuitry may be used in place of, or in combination with, softwareinstructions for implementation of the processes of the presentinvention. Thus, embodiments of the present invention are not limited toany specific combination of hardware and software. As discussed withrespect to system 250 of FIG. 2B, execution of sequences of theinstructions in a program of a peripheral device 240 in communicationwith gaming device 300 may also cause processor 305 to perform some ofthe process steps described herein.

The memory 310 also stores a plurality of databases, including aprobability database 320, and a payout database 325. Note, althoughthese databases are described as being stored in a gaming device, inother embodiments of the present invention some or all of thesedatabases may be partially or wholly stored in another device, such asone or more of the peripheral devices 240, the peripheral device server245 and/or the computer 210. Further, some or all of the data describedas being stored in the databases 320, 325 may be partially or whollystored (in addition to or in lieu of being stored in the memory 310 ofthe gaming device 300) in a memory of one or more other devices, such asone or more of the peripheral devices 240, another gaming device 230,the peripheral device server 245 and/or the computer 210.

The databases 320 and 325 are well known in the art, and need not bedescribed in detail herein. Also, some enabled games may not requireprobability database 320 and/or payout database 325. The processor 305is also operable to communicate with a random number generator 345,which may be a component of gaming device 300. The random numbergenerator, in accordance with at least some embodiments of the presentinvention, may generate data representing random or pseudo-random values(referred to as “random numbers” herein). The random number generatormay generate a random number every predetermined unit of time (e.g.every second) or in response to an initiation of a game on the gamingdevice. In the former embodiment, the generated random numbers may beused as they are generated (e.g. the random number generated atsubstantially the time of game initiation is used for that game) and/orstored for future use.

A random number generator, as used herein, may be embodied as aprocessor separate from but working in cooperation with processor 305.Alternatively, random number generator 345 may be embodied as analgorithm, program component, or software stored in the memory of gamingdevice 300 and used to generate a random number.

Note that, although the generation or obtainment of a random number isdescribed herein as involving a random number generator of a gamingdevice, other methods of determining a random number may be employed.For example, a gaming device owner or operator may obtain sets of randomnumbers that have been generated by another entity. HOTBITS™, forexample, is a service that provides random numbers that have beengenerated by timing successive pairs of radioactive decays detected by aGeiger-Muller tube interfaced to a computer. A blower mechanism thatuses physical balls with numbers thereon may be used to determine arandom number by randomly selecting one of the balls and determining thenumber thereof.

The processor 305 is also operable to communicate with a benefit outputdevice 350, which may be a component of gaming device 300. The benefitoutput device 350 may comprise one or more devices for outputting abenefit to a player of the gaming device 300. For example, in someembodiments the gaming device 300 may provide coins and/or tokens as abenefit. In such an embodiment the benefit output device 350 maycomprise a hopper and hopper controller, for dispensing coins and/ortokens into a coin tray of the gaming device 300. In another example,the gaming device 300 may provide a receipt or other document on whichthere is printed an indication of a benefit (e.g. a cashless gamingreceipt that has printed thereon a monetary value, which is redeemablefor cash in the amount of the monetary value). In such an embodiment thebenefit output device 350 may comprise a printing and documentdispensing mechanism. In yet another example, the gaming device 300 mayprovide electronic credits as a benefit (which, e.g. may be subsequentlyconverted to coins and/or tokens and dispensed from a hopper into a cointray). In such an embodiment the benefit output device 350 may comprisea credit meter balance and/or a processor that manages the amount ofelectronic credits that is indicated on a display of a credit meterbalance. The processor may be the processor 305 or another processor. Inyet another example, the gaming device 300 may credit a monetary amountto a financial account associated with a player as a benefit provided toa player. The financial account may be, for example, a credit cardaccount, a debit account, a charge account, a checking account, or acasino account. In such an embodiment the benefit output device maycomprise a device for communicating with a server on which the financialaccount is maintained.

Note that, in one or more embodiments, the gaming device 300 may includemore than one benefit output device 350 even though only one benefitoutput device is illustrated in FIG. 3. For example, the gaming device300 may include both a hopper and hopper controller combination and acredit meter balance. Such a gaming device may be operable to providemore than one type of benefit to a player of the gaming device. A singlebenefit output device 350 may be operable to output more than one typeof benefit. For example, a benefit output device 350 may be operable toincrease the balance of credits in a credit meter and communicate with aremote device in order to increase the balance of a financial accountassociated with a player.

The processor 305 is also operable to communicate with a display device355, which may be a component of gaming device 300. The display device355 may comprise, for example, one or more display screens or areas foroutputting information related to game play on the gaming device, suchas a cathode ray tube (CRT) monitor, liquid crystal display (LCD)screen, or light emitting diode (LED) screen.

In one or more embodiments, a gaming device may comprise more than onedisplay device. For example, a gaming device may comprise an LCD displayfor displaying electronic reels and a display area that displaysrotating mechanical reels.

The processor 305 may also be in communication with one or more otherdevices besides the display device 355, for outputting information(e.g., to a player or another device). Such other one or more outputdevices may also be components of gaming device 300. Such other one ormore output devices may comprise, for example, an audio speaker (e.g.for outputting an offer for a feature or information related thereto, inaddition to or in lieu of such information being output via a displaydevice 355), an infra-red transmitter, a radio transmitter, an electricmotor, a printer (e.g., such as for printing cashless gaming vouchers),a coupon or product dispenser, an infra-red port (e.g., forcommunicating with a second gaming device or a portable device of aplayer), a Braille computer monitor, and a coin or bill dispenser. Forgaming devices, common output devices include, but are not limited to, acathode ray tube (CRT) monitor on a video poker machine, a bell on agaming device (e.g., rings when a player wins), an LED display of aplayer's credit balance on a gaming device, and an LCD display of apersonal digital assistant (PDA).

The display device 355 may comprise, for example, one or more displayareas. For example, one of the display areas may display outcomes ofgames played on the gaming device (e.g. electronic reels of a gamingdevice). Another of the display areas may display rules for playing agame of the gaming device. Yet another of the display areas may displaythe benefits obtainable by playing a game of the gaming device (e.g., inthe form of a payout table). In one or more embodiments, the gamingdevice 300 may include more than one display device, one or more otheroutput devices, or a combination thereof (e.g., two display devices andtwo audio speakers).

The processor 305 is also in communication with an input device 365,which is a device that is capable of receiving an input (e.g., from aplayer or another device) and which may be a component of gaming device300. An input device may communicate with or be part of another device(e.g. a server, a gaming device, etc.). Some examples of input devicesinclude: a bar-code scanner, a magnetic stripe reader, a computerkeyboard or keypad, a button, a handle, a keypad, a touch-screen, amicrophone, an infrared sensor, a voice recognition module, a coin orbill acceptor, a sonic ranger, a computer port, a video camera, a motiondetector, a digital camera, a network card, a universal serial bus (USB)port, a GPS receiver, a radio frequency identification (RFID) receiver,an RF receiver, a thermometer, a pressure sensor, an infrared port(e.g., for receiving communications from with a second gaming device oranother device such as a smart card or PDA of a player), and a weightscale. For gaming devices, common input devices include a button ortouch screen on a video poker machine, a lever or handle connected tothe gaming device, a magnetic stripe reader to read a player trackingcard inserted into a gaming device, a touch screen for input of playerselections during game play, and a coin and bill acceptor.

The processor 305 is also in communication with a payment system 375,which may be a component of gaming device 300. The payment system 375 isa device capable of accepting payment from a player (e.g., a bet orinitiation of a balance) and/or providing payment to a player (e.g., apayout). Payment is not limited to money, but may also include othertypes of consideration, including products, services, and alternatecurrencies.

Exemplary methods of accepting payment by the payment system 375 include(i) receiving hard currency (i.e., coins or bills), and accordingly thepayment system 375 may comprise a coin or bill acceptor; (ii) receivingan alternate currency (e.g., a paper cashless gaming voucher, a coupon,a non-negotiable token), and accordingly the payment system 375 maycomprise a bar code reader or other sensing means; (iii) receiving apayment identifier (e.g. a credit card number, a debit card number, aplayer tracking card number) and debiting the account identified by thepayment identifier; and (iv) determining that a player has performed avalue-added activity.

In some embodiments, a player may operate a plurality of gaming devices.For example, a player may simultaneously play two side-by-side gamingdevices, a player may play one gaming device (e.g. a gaming device) andthen continue his gaming session at another gaming device (e.g. a videopoker machine), and a player may remotely operate a gaming device,possibly by using a telephone, PDA or other device (i) to transmitcommands (directly or indirectly) to the gaming device, such as wageramounts and commands to select certain cards; and/or (ii) to receiveoutput (directly or indirectly) from the gaming device.

In some embodiments, a gaming device may allow a player to play a gameof skill rather than a game of chance. Such an embodiment may be moreappealing to certain players or may be permitted in areas where it isillegal to gamble on games of chance.

Referring now to FIG. 4, illustrated therein is a block diagram of anembodiment 400 of computer 210 (FIG. 2A and FIG. 2B). The computer 400may be implemented as a system controller, a dedicated hardware circuit,an appropriately programmed general-purpose computer, or any otherequivalent electronic, mechanical or electromechanical device. Thecomputer 400 may comprise, for example, a server computer operable tocommunicate with one or more client devices, such as gaming devices 230.The computer 400 is operative to manage the system 200 and the system250 and execute the methods of the present invention.

In operation, the computer 400 may function under the control of acasino, a merchant, or other entity that may also control use of thegaming devices 230, peripheral devices 240, and/or peripheral deviceserver 245. For example, the computer 400 may be a slot server in acasino. In some embodiments, the computer 400 and slot server may bedifferent devices. In some embodiments, the computer 400 may comprisemore than one computer operating together. In some embodiments, thecomputer 400 and peripheral device server 245 may be the same device.

The computer 400 comprises a processor 405, such as one or more INTEL®PENTIUM® processors. The processor 405 is in communication with a memory410 and a communications port 415 (e.g., for communicating with one ormore other devices). The memory 410 may comprise an appropriatecombination of magnetic, optical and/or semiconductor memory, and mayinclude, for example, Random Access Memory (RAM), Read-Only Memory(ROM), a compact disc and/or a hard disk. The processor 405 and thememory 410 may each be, for example: (i) located entirely within asingle computer or other device; or (ii) connected to each other by aremote communication medium, such as a serial port cable, telephone lineor radio frequency transceiver. In some embodiments, the computer 400may comprise one or more devices that are connected to a remote servercomputer for maintaining databases.

The memory 410 stores a program 420 for controlling the processor 405.The processor 405 performs instructions of the program 420, and therebyoperates in accordance with the present invention, and particularly inaccordance with the methods described in detail herein. The program 420may be stored in a compressed, uncompiled and/or encrypted format. Theprogram 420 furthermore includes program elements that may be necessary,such as an operating system, a database management system and “devicedrivers” for allowing the processor 405 to interface with computerperipheral devices. Appropriate program elements are known to thoseskilled in the art, and need not be described in detail herein.

According to an embodiment of the present invention, the instructions ofthe program 420 may be read into a main memory from anothercomputer-readable medium, such from a ROM to RAM. Execution of sequencesof the instructions in program 420 causes processor 405 to perform theprocess steps described herein. In alternate embodiments, hard-wiredcircuitry may be used in place of, or in combination with, softwareinstructions for implementation of the processes of the presentinvention. Thus, embodiments of the present invention are not limited toany specific combination of hardware and software.

The memory 410 also stores a plurality of databases, including a featuredatabase 425, a condition database 430, a gaming device database 435, aplayer database 440, a performance database 445, and a payment database450. Each of these databases is described in detail below and examplestructures are depicted with sample entries in the accompanying figures.As will be understood by those skilled in the art, the schematicillustrations and accompanying descriptions of the sample databasespresented herein are exemplary arrangements for stored representationsof information. Any number of other arrangements may be employed besidesthose suggested by the tables shown. For example, even though sixseparate databases are illustrated, the invention could be practicedeffectively using any number of more or fewer functionally equivalentdatabases. Similarly, the illustrated entries of the databases representexemplary information only; those skilled in the art will understandthat the number and content of the entries can be different from thoseillustrated herein. Further, despite the depiction of the databases astables, an object-based model could be used to store and manipulate thedata types of the present invention and likewise, object methods orbehaviors can be used to implement the processes of the presentinvention.

Note that, although these databases are described as being stored in agaming device, in other embodiments of the present invention some or allof these databases may be partially or wholly stored in another device,such as one or more of the peripheral devices 240, the peripheral deviceserver 245, one or more of the gaming devices 230, a slot server (ifdifferent from the computer 210), another device, or a combinationthereof. Further, some or all of the data described as being stored inthe databases 425, 430, 435, 440, 445, and 450 may be partially orwholly stored (in addition to or in lieu of being stored in the memory410 of the computer 400) in a memory of one or more other devices, suchas one or more of the peripheral devices 240, one or more of the gamingdevices 230, the peripheral device server 245 and/or a slot server (ifdifferent from computer 210).

Referring now to FIG. 5, an exemplary tabular representation 500illustrates an embodiment of the feature database 425 (FIG. 4) that maybe stored in the computer 400. The tabular representation 500 of thefeature database includes a number of example records or entries, eachdefining a feature that may be enabled on a gaming device 300 by thecomputer 400 (or the gaming device 300). Those skilled in the art willunderstand that the feature database may include any number of entries.

The tabular representation 500 also defines fields for each of theentries or records. The fields specify: (i) a feature identifier 502that uniquely identifies a particular feature (e.g., uniquely identifiesa particular option, mode, or parameter for affecting the operation ofone or more games and/or one or more gaming devices), (ii) a featurename 504 that includes a name of the particular feature, (iii) adescription 506 that contains a description (e.g., a text description)of the enhancement(s) provided by the feature to play on a gamingdevice, and (iv) a category 508 that stores an indication of a group orcategory of features with which the feature may be identified.

The feature name 504, the category 508, and/or the description 506 maybe used in outputting information and messages to a player (e.g., atdisplay device 355 of the gaming device 300). For example, a player mayreceive a displayed offer: “Click here for Free Telephone Calls!”. Inanother example, the player's selection of a feature from a list ofdisplayed features may cause the description 506 to be displayed in adisplay area of a gaming device.

Referring now to FIG. 6, an exemplary tabular representation 600illustrates an embodiment of the condition database 430 (FIG. 4) thatmay be stored in the computer 400. The tabular representation 600 of thecondition database includes a number of example records or entries, eachdefining a condition that may used, for example, for determining whethera feature should be enabled (or disabled) on a gaming device 300 by thecomputer 400 (or the gaming device 300). Those skilled in the art willunderstand that the condition database may include any number ofentries.

The tabular representation 600 also defines fields for each of theentries or records. The fields specify: (i) a feature identifier 602that identifies a particular feature, and (ii) a condition for enablingfeature 604 that includes an indication of one or more requirements thatmust be satisfied in order to enable (or to keep enabled) the particularfeature.

As discussed herein, a condition for enabling feature 604 may correspondto one or more requirements for enabling a feature (and/or for keepingan enabled feature enabled). A condition may alternatively correspond toone or more requirements for disabling a feature (and/or for keeping thefeature disabled). Those skilled in the art will readily understand thata condition described as a condition for enabling a feature may suggesta condition for disabling a feature, and vice versa. For example, acondition that no more than fifty players can be playing a particulartype of slot machine in order for a particular feature to be enabled mayalso suggest a condition that the feature is to be disabled if thenumber of players exceeds fifty.

In some embodiments, however, a condition for disabling or enabling afeature may not necessarily suggest its opposite. For example, adescribed condition may indicate that a disabled feature should beenabled if ten or more players are playing video poker. However, thefeature, once enabled, may or may not be disabled if the number ofplayers playing video poker falls below ten, for example.

Various types of information and factors on which conditions may bebased are described herein, and other criteria and requirements will bereadily understood by one skilled in the art in light of the presentdisclosure. Some examples of conditions include, but are not limited to:

-   -   (i) Whether an amount of revenue generated at a gaming device        while a feature is being used (e.g., an amount of coin-in and/or        transaction amounts received from players in association with        offers for products/services and other transactions at the        gaming device) exceeds a predetermined minimum threshold;    -   (ii) Whether an average amount wagered by a player (or players)        while a feature is in use is greater than a historical average        wager amount of the player;    -   (iii) An identity of a player operating the gaming device (e.g.        some features may be available only to certain players, or only        to players who use player tracking cards);    -   (iv) Past gambling activity of a player (e.g. whether the        year-to-date coin-in by a player is less than a predetermined        threshold);    -   (v) Current gambling activity (e.g., activity during a current        session, or during a current trip to a casino) of a player (e.g.        whether a current credit balance is less than a predetermined        maximum amount, or whether an average rate of play during a        current gaming session is greater than a predetermined threshold        for enabling the feature);    -   (vi) Anticipated future gambling activity of a player (e.g.        whether a particular player (or players) is likely to stop        gambling within the next ten minutes);    -   (vii) A preference of one or more players (e.g., whether a        majority of players prefer a particular feature, or whether a        particular player has previously indicated a preference for the        feature);    -   (viii) A game that a player is currently playing (e.g., a        feature for providing an interactive tour of a game's bonus        round may be enabled if the player is currently playing a game        that is relatively new to the casino);    -   (ix) A type of gaming device a player is currently playing        (e.g., a feature may be enabled for video poker machines but not        for video blackjack machines);    -   (x) A location of the gaming device (e.g., a feature may be        enabled if the gaming device is near a door of a casino floor,        but may not be enabled if the gaming device is near a poker        room);    -   (xi) Information about the compatibility or suitability of the        feature with a game and/or with the gaming device (e.g., a        feature for providing an interactive tour of a game's bonus        round may not be enabled for a game that does not have a bonus        round, or for a gaming device offering only games without bonus        rounds);    -   (xii) A manufacturer that produces a gaming device (e.g. a        feature may only be enabled at the gaming device if the gaming        device is produced by a specific manufacturer);    -   (xiii) A developer, licensor, vendor, or other provider of a        feature (e.g. a feature may only be enabled on gaming devices        whose manufacturers have agreements with the provider of the        feature); and    -   (xiv) A developer, licensor, vendor, or other provider of a game        available on the gaming device (e.g., a game vendor may        stipulate that only certain types of features may be enabled on        devices offering its games).

In some embodiments, the predetermined condition may be based on thetime of day. For example, a feature for providing a tour of a slotmachine may be disabled between the hours of 8 p.m. and 11 p.m.(typically peak hours for gambling), because the operator of the slotmachine is aware that players tend to operate the slot machine inregular mode during these hours anyway.

Examples of time-related predetermined conditions that may need to besatisfied before a feature is enabled on a gaming device include, butare not limited to:

-   -   (i) A period of time since an event (e.g., the feature may be        automatically disabled after a certain period of time after the        feature is initially enabled, after the feature is first used,        after the feature is used a predetermined number of times,        etc.); and    -   (ii) A time of day (e.g., the feature may be disabled during        particular times of the day).

Other appropriate time-related predetermined conditions will berecognized by one of ordinary skill in the art after reading the presentapplication. Examples of predetermined conditions related to indicationsfrom parties, that may need to be satisfied before a feature is enabledon the gaming device include, but are not limited to:

-   -   (i) Whether a signal was provided, by or on behalf of a casino        or other operator of the gaming device, indicating that the        feature should be enabled (e.g., a signal received from a casino        employee observing a player becoming bored and/or discouraged in        playing the gaming device);    -   (ii) Whether a signal was provided, by or on behalf of a        regulatory group (e.g., a state, federal, or local government        agency for regulating gambling activities), indicating that the        feature can (or must) be enabled (e.g., a signal received from a        state gaming commission indicating that the feature meets        regulatory approval); and    -   (iii) Whether a signal was provided, by or on behalf of a        provider of the feature (e.g., a game manufacturer, a patent        holder), indicating that the feature can be enabled.

Other appropriate predetermined conditions related to indicationsreceived from or otherwise provided by any of various parties will berecognized by one of ordinary skill in the art after reading the presentapplication. Note that indications such as those discussed herein may beprovided in a variety of different ways, including, but not limited to:(i) using an input device of a server computer (e.g. a keyboard); (ii)using an input device of a gaming device (e.g. a touch screen); and(iii) using a peripheral device (described in further detail herein) incommunication with a server computer and/or a gaming device.

In some embodiments, the provided indication from a party may comprisean authorization code, as discussed further herein. Examples ofpredetermined conditions related to authorization codes, that may needto be satisfied before a feature is enabled on the gaming deviceinclude, but are not limited to:

-   -   (i) Whether at least one authorization code has been provided;    -   (ii) A period of time since at least one authorization code was        provided (e.g., thirty days ago); and    -   (iii) A type of authorization code that has been provided (e.g.,        different authorization codes may enable the same feature in        different ways, such as for different periods of time).

Other appropriate predetermined conditions related to authorizationcodes will be recognized by one of ordinary skill in the art afterreading the present application. Examples of predetermined conditionsrelated to information about a casino that may need to be satisfiedbefore a feature is enabled on the gaming device include, but are notlimited to:

-   -   (i) What casino operates a gaming device (e.g., a feature may be        enabled at a first casino but is to be disabled at a second        casino, even if the casinos are commonly owned or operated and        may have access to the same features);    -   (ii) A location or jurisdiction of a casino (e.g. a feature may        be disabled within a first geographic region, such as the state        of Nevada, but enabled within a second geographic region, such        as an American Indian reservation in the state of Arizona);    -   (iii) A measure of usage of gaming devices at a casino (e.g., a        tutorial feature on how to play the bonus round on a particular        type of slot machine may be disabled if more than 90% of all        such machines are in use, as the clear demand for the slot        machines indicates that there is no need to entice additional        players by enabling the tutorial feature); and    -   (iv) Revenue management information for a casino (e.g., one or        more conditions may be established to maximize revenue, such as        by establishing a condition that if a casino hotel is only half        full, then a feature that offers hotel rooms to players should        be enabled).

Other appropriate predetermined conditions related to information abouta casino will be recognized by one of ordinary skill in the art afterreading the present application.

Another example of a predetermined condition comprises a minimum numberof games played by a player on a gaming device. For example, it may bedetermined that it is desirable that a player playing one hundred gameson a gaming device should be rewarded by enabling a feature on thegaming device.

In another example, it may be determined whether an outcome determinedfor a player playing a game at the determined gaming device satisfies apredetermined condition for enabling a feature. For instance, a gamingdevice may determine an outcome in a manner well known in the art. Anoutcome, as used herein, comprises at least one indicia that is utilizedto inform a player of whether a benefit (e.g., a payout) has been won bythe player as a result of playing a game. In a reeled slot machine game,for example, a set of symbols displayed along a payline comprises anoutcome of a game. Some of the possible combinations of symbolsobtainable on the reeled slot machine correspond to a payout. Thus, aplayer is informed of whether he has won a payout by displaying a set ofsymbols along the payline. If the set of symbols along the paylinecorrespond to a payout (e.g., as displayed on a payout table of thereeled slot machine), then the player is informed that he has won thecorresponding payout once the set of symbols is displayed along thepayline. In a video poker gaming device, as another example, the set ofcards comprising the final hand comprises the outcome of a game.

The above examples of predetermined conditions have been provided forpurposes of illustrating various embodiments consistent with the process100D (FIG. 1D), and with some other methods for determining whether afeature should be enabled or disabled on a gaming device. Other types ofpredetermined conditions and types of information on which suchconditions may be based, are described herein.

Referring now to FIG. 7, an exemplary tabular representation 700illustrates an embodiment of the gaming device database 435 (FIG. 4)that may be stored in the computer 400. The tabular representation 700of the gaming device database includes a number of example records orentries, each defining a gaming device that may be in communication(e.g., over a LAN or WAN) with computer 400. Those skilled in the artwill understand that the gaming device database may include any numberof entries.

The tabular representation 700 also defines fields for each of theentries or records. The fields specify: (i) a gaming device identifier702 that uniquely identifies a particular gaming device (e.g., uniquelyidentifies a particular slot machine on a casino floor or a PCcommunicating with an online casino), (ii) a gaming device type 704 thatstores a description or designation of the type of gaming device, (iii)a features enabled 706 that stores an indication or identifier of one ormore features currently enabled on the gaming device, (iv) a features inuse 708 that stores an indication or identifier of one or more featurescurrently being used on the gaming device, (v) a benchmark theoreticalwin 710 that indicates a theoretical win for the gaming device (e.g., ahistorical theoretical win), and (vi) a location 712 that stores anindication of the physical location of the particular gaming device.

The gaming device database may be used by computer 400 to, for example,communicate with one or more gaming devices and to identify a gamingdevice that data is being transmitted to or received from. For example,the computer 400 may instruct a gaming device as to which featuresshould be enabled and/or made active at the gaming device, transmit arandom number to the gaming device, transmit an indication of a featurefor use by the gaming device, update information in one or moredatabases of the gaming device, and receive information associated witha player of the gaming device (e.g., a player identifier, playerpreferences, an indication of wagers placed or number of games played bya player, an indication of duration of play by a player at the gamingdevice, etc.). Some of this information may be stored in associationwith the gaming device. For example, the gaming device may store anindication of the last time that a feature was made active on aparticular gaming device.

The gaming device type 704 stores an indication of what types of gamesare available on the particular gaming device. Such information may beused, for example, to determine whether to enable a feature on a gamingdevice. For example, in some embodiments it may be desirable that aparticular feature is not made available for use at video blackjackmachines during particular times of day. Accordingly, the computer 400may consider whether a gaming device is a video blackjack machine andthe time of day in determining whether a feature should be enabled onthe gaming device.

The features enabled 706 stores an indication of what features arecurrently enabled for use on the particular gaming device, and thefeatures in use 708 stores an indication of what features are currentlyactive on the particular gaming device. Such information may be used,for example, to determine whether to enable a feature on a gamingdevice. For example, in some embodiments it may be desirable that afirst feature is not made active if a second feature is already activeon the particular gaming device. For instance, a rule or condition mayspecify that the first feature should only be enabled if the secondfeature is not active on the gaming device. Further, such informationmay be used, for example, to track the usage of different features. Forinstance, features in use 708 can be used to determine how many gamingdevices a particular feature is active on at any given time.

The benchmark theoretical win 710 stores an indication of a theoreticalwin of the gaming device that may be used, for example, as the basis fordetermining whether one or more features can be correlated to an effecton the theoretical win of a particular gaming device. For example,benchmark theoretical win 710 may be a value determined with respect toa particular period of time, such as a period of time preceding when aparticular feature was first enabled on the gaming device. A secondtheoretical win may be calculated for a period during which the featurehas been enabled. Thus, any difference between the benchmark and thetheoretical win while the feature has been enabled may be correlated tothe feature as a useful measure of performance of the feature. Forinstance, if the enabling of the feature is correlated to an increase inthe theoretical win for the gaming device, then it may be determined(e.g. by a slot server) to keep the feature enabled based on thisincreased performance. In another example, the benchmark theoretical win710 may be of a different gaming device, or may be an average for two ormore gaming devices. For instance, such benchmarks may be useful indetermining any difference in theoretical win between gaming deviceshaving different features in use, or for comparing a gaming device withno features active to one having one or more features active.

Although a benchmark theoretical win is described above with respect toa gaming device, it will be readily understood that other types ofbenchmark values may be used, in addition to or in lieu of a theoreticalwin value. For example, benchmark values may be established appropriatefor comparison with various types of measures of performance, usage,and/or profitability. Some examples of benchmark values include, but arenot limited to, a number of handle pulls per hour, a number of paylinesactivated on a slot machine, and an average wager size per handle pull.Benchmark values may also be established for information related toancillary entities (e.g. sponsors of offers made available in accordancewith a feature). Some examples include, but are not limited to, a numberof restaurant covers, an average price per check (e.g. in a restaurant),an occupancy of a showroom or theater, an average daily room rate at ahotel, and a percentage of rooms that are occupied in a hotel.

The gaming device location 712 stores an indication of where aparticular gaming device is located. Such information may be used, forexample, to determine whether a feature should be enabled on a gamingdevice. For example, in some embodiments it may be desirable that aparticular feature be enabled for play of one gaming device in adesignated area of a casino per predetermined period of time (e.g., atleast once every five minutes for a particular bank of slot machines).Accordingly, the computer 400 may track when the feature is enabled and,if this has not occurred within a predetermined period of time in adesignated area of a casino, the computer 400 may select a gaming devicein that area and instruct it to enable the feature for play.

Referring now to FIG. 8, an exemplary tabular representation 800illustrates an exemplary embodiment of a player database 440 (FIG. 4)that may be stored in computer 400. The tabular representation 800 ofthe player database includes a number of example records or entries,each defining a player who may be a member of a slot club of a casino orotherwise registered with or known to a casino or other entity. Thoseskilled in the art will understand that the player database may includeany number of entries.

The tabular representation 800 also defines fields for each of theentries or records. The fields specify: (i) a player identifier 802 thatuniquely identifies a player, (ii) a name 804 of a player, (iii) afinancial account identifier 806 associated with a player, (iv) anindication of comp points 808 available to a player, (v) a theoreticalwin/[loss] 810, (vi) an actual win/[loss] 812 for a player, and (vii) afeature preference(s) 814.

The information in the player database 440 may be created and updated,for example, based on information received from a player, a casinoemployee, a gaming device 230, a peripheral device 240, and/orperipheral device server 245. For example, the information may becreated when a player registers with a casino and receives a playertracking card encoded with the player identifier. The information may besubsequently updated when a player requests to update the information(e.g. when a player indicates a desire to change a preferred feature) orwhen additional information is obtained about the player via thecasino's interactions with the player (e.g. the lifetime theoretical winmay be updated on an ongoing basis as the player plays games at acasino).

The player identifier 802 may be, for example, an alphanumeric codeassociated with a player who may operate a gaming device or play a tablegame at a casino. The player identifier 802 may be generated orselected, for example, by the computer 210 or by the player (e.g. when aplayer first registers with a casino). For each player, the playerdatabase 440 may also store the player's name 804 (e.g., for use inoutputting messages to the player). In one or more embodiments theplayer's name may comprise a nickname or other designation for theplayer that is selected by the player or the casino. In one or moreembodiments, the nickname may comprise a designation that reflects theplayer's status (e.g., “premium player”). Such a status may indicate,for example, the typical spending range of the player or otherindication of how valuable the player is considered to be by the casino.Such a designation may or may not be known to the player.

The financial account identifier 806 (e.g., a credit card accountnumber, a debit card account number, a checking account number, a casinofinancial account number, or digital payment protocol information)associated with the player. The financial account identifier 806 may beused, for example, to credit a payment to the player (e.g., wherein abenefit obtained by the player comprises a monetary amount) and/or todebit a wager amount.

The comp points 808 stores an indication of the number of comp pointsthat a player is currently entitled to. Comp point programs are a commonmethod for a casino to reward players by awarding points to players as areward for certain gambling behavior that a casino finds desirable.Although the comp points programs differ from casino to casino, in atypical comp point program a player accumulates comp points based on (i)a total amount of coins wagered, or (ii) a total amount of coins paidout. Alternatively, comp points may be awarded based on, for example,(i) the length of time or a number of game plays at a gaming device ortable game; (ii) the average wager of a player; and/or (iii) for playinga particular gaming device or group of gaming devices. As the playeraccumulates comp points the player may exchange some or all of the comppoints for goods or services specified by the comp point program. Forexample, a player may exchange 800 comp points for a dinner at a casinorestaurant. As the player exchanges comp points for a good or servicethe exchanged comp points are deducted from the player's comp pointbalance reflected in field 808 of tabular representation 800. In somecomp point programs the rewards are defined in terms of dollar amountsrather than points. In yet other comp point programs the points areexchangeable into dollar amounts based on a schedule defined by thecasino, allowing the player to convert the accumulated points intodollar amounts and then use the dollar amounts to purchase goods orservices from the casino.

The theoretical win/[loss] 810 stores an indication of the theoreticalwin of the casino based on the playing activity of the player since theplaying activity of the player has been tracked. In other words, thehistorical theoretical win/[loss] 810 may be a “lifetime” theoreticalwin. In other embodiments a historical theoretical win/[loss] based onother periods of time may be stored in addition to or instead of thelifetime historical theoretical win/[loss]. For example, an annual orsession theoretical win/[loss] may be stored. The actual win/[loss] 812stores an indication of the actual dollar amount that the correspondingplayer has won or lost while gambling at the casino. A casino loss isindicated in brackets in the tabular representation 800.

In some embodiments of the present invention, a determination of whetherto enable a feature on a gaming device and/or whether to offer toactivate a feature for a player may be based on the theoreticalwin/[loss] and/or actual win/[loss] of the player playing the game. Forexample, using the process 100D, in step 165 it may be determined if twopredetermined conditions have been satisfied: (i) that a player's actualwin/[loss] is a loss of at least a predetermined value (assuming, forthis example, that the win/[loss] is calculated for a particular gamingsession); and (ii) that the gaming device at which the player is playingis compatible with the feature. Satisfaction of these two predeterminedconditions may correspond to enabling the feature for use on theplayer's gaming device.

It should be understood that although a player identifier andinformation related to each registered player is described in detail, aplayer need not be registered in order to be able to use featuresenabled on a gaming device. Accordingly, registration of a player andstoring of information related to a player is not necessary for practiceof the present invention.

The feature preference(s) 814 store one or more preferences for afeature. For example, a preference may be that a particular feature isenabled on whatever gaming device the player is playing. Such playerpreferences may be provided by the player directly. For example, aplayer may tell a casino employee, who may in turn enter an indicationof the preference to the player database. In another example, a playermay be prompted by a gaming device 230 to store a current configurationof one or more features as a feature preference. Alternatively, a playerpreference may be determined indirectly. For example, a casino employeemay observe a player's reaction and decide that the player really doesnot like a particular feature or that a player really enjoys aparticular type of offer that may be provided in accordance with one ormore features. In another example of how a player preference may bedetermined indirectly, a player's gambling behavior may be tracked todetermine whether a player continues to keep playing for an extendedperiod of time or stops playing shortly after a particular feature ismade active.

According to some embodiments, some or all of the exemplary informationdepicted in FIG. 8 may be stored on a player tracking card. For example,an indication of one or more feature preferences of a player may bestored on a player tracking card and accessed by one or more gamingdevices 230, peripheral device server 245, another peripheral device240, and/or computer 210.

Referring now to FIG. 9A, an exemplary tabular representation 900Aillustrates an exemplary embodiment of a performance database 445 (FIG.4) that may be stored in computer 400. The tabular representation 900Aof the performance database includes a number of example records orentries, each defining a gaming session of a player at a gaming device.Those skilled in the art will understand that the performance databasemay include any number of entries.

The tabular representation 900A also defines fields for each of theentries or records. The fields specify: (i) a session identifier 902that uniquely identifies a session of gaming activity by a player, (ii)a gaming device identifier 904 that identifies a gaming device at whichthe player's gaming activity takes place, (iii) a player identifier 906that identifies a player participating in the gaming session, (iv) alength of session 908 that includes an indication of the duration of theparticular gaming session, (v) a total coin-in 910 that indicates atotal amount wagered by the player during the session, (vi) a sessiontheoretical win per minute 912, (vii) an increase in theoretical win perminute 914 that indicates a difference between the session theoreticalwin per win and a particular benchmark value (e.g., benchmarktheoretical win 710 of FIG. 7), and (viii) an active features 916 thatindicates one or more features that are or were active during theparticular session.

The information in this exemplary embodiment of the performance database440 may be created and updated, for example, based on informationreceived from a player, a casino employee, a gaming device 230, aperipheral device 240, and/or peripheral device server 245. For example,the information may be created when a player inserts his player trackingcard at a gaming device 230 (e.g. a new session entry may be createdwhenever a player is first identified at a gaming device). Theinformation may be updated subsequently when additional information isobtained about the player via the player's interactions with the gamingdevice during a session. For example, the total coin-in, and indicationsof the active features may be updated on an ongoing basis as the playerplaces wagers at the gaming device and selects different features. Inanother example, the session theoretical win per minute (and theincrease in theoretical win per minute) may be updated on an ongoingbasis during a session (or, alternatively, only at the end of a session)based on the player's wagering.

Information stored this exemplary embodiment of the performance database445 may be used in making various determinations for managing features.In some embodiments of the present invention, a determination of whetherto enable or disable a feature on a gaming device, and/or whether tooffer to activate a feature for a player, may be based on the totalcoin-in, session theoretical win per minute and/or the increase intheoretical win per minute. For example, using the process 100B, in step135, the determination of whether to disable one or more enabledfeatures may be based on a measure of performance such as the totalcoin-in, the session theoretical win per minute, and/or the increase intheoretical win per minute. If the increase in theoretical win perminute is greater than a predetermined value, the enabled features mayremain enabled. Otherwise, they may be disabled. Note that such adetermination need not take place during the player's session, but mayoccur at any time (e.g., in accordance with a schedule for managing thefeatures of the system).

In one or more embodiments of the present invention, some of theinformation stored in the exemplary embodiment of the performancedatabase 445 may be used to determine payment for a provider of afeature, game, or gaming device. For example, using the process 100D, insteps 175-185 the total coin-in may be used as a measure of usage indetermining a payment

It should be understood that the sessions depicted in the tabularrepresentation 900A are for illustrative purposes only. In someembodiments, a player's session may include information about play ofmore than one gaming device, and may include information about one ormore periods of time in which the player was not playing a gaming device(e.g., the session may correspond to an entire week stay at a casinohotel). FIG. 9C, for example, depicts exemplary information representinga player's trip to a casino, and is discussed in detail below.

Referring now to FIG. 9B, an exemplary tabular representation 900Billustrates another exemplary embodiment of a performance database 445(FIG. 4) that may be stored in computer 400. The tabular representation900B of the performance database includes a number of example records orentries, each defining a gaming session in which an exemplary feature“Free Telephone Calls” was used. Those skilled in the art willunderstand that the performance database may include any number ofentries.

The tabular representation 900B also defines fields for each of theentries or records. The fields specify: (i) a session identifier 920that uniquely identifies a session in which the exemplary feature wasused, (ii) a length of session 922 that includes an indication of theduration of the particular gaming session, (iii) a coin-in per minute924 that indicates the total coin-in for the session averaged on a perminute basis, (iv) a session theoretical win per minute 926, (v) a totalcost of calls 928 that indicates a cost of providing the “Free TelephoneCalls” during the session, and (vi) a net theoretical profit fromsession 930 that indicates a difference between the costs incurred inproviding the feature and the session theoretical win.

As discussed above with respect to the tabular representation 900A ofFIG. 9A, the information in this exemplary embodiment of the performancedatabase 440 may be created and updated, for example, based oninformation received from a player, a casino employee, a gaming device230, a peripheral device 240, and/or peripheral device server 245.Similarly, information may be created at the start of a session (e.g.,when a player inserts his player tracking card at a gaming device 230),and may be updated subsequently (e.g., as the player uses the feature tomake telephone calls, thereby incurring costs to the system and possiblyaffecting the net theoretical profit of the session).

Various types of information represented in this exemplary embodimentmay be used in managing features for gaming devices. For example, thelength of session 922 may be helpful as a measure of usage (e.g., indetermining whether to keep the feature enabled, in determining whetherto enable the feature on additional gaming devices, in determining anamount due to a provider of the feature).

As discussed variously herein, a measure of profitability of a gamingdevice (e.g., based on revenue generated at the gaming device) can beuseful in managing features on the gaming device (e.g., in determiningwhether to enable or disable certain features). Note that the particularfeature “Free Telephone Calls” incurs a cost (e.g., to the casinoproviding the telephone service) when it is used by players.Accordingly, a measure of performance of a gaming device and/or of afeature may be based on information about costs of the feature itself(e.g., how profitable it is to provide the feature in light of itsassociated costs). In some embodiments, a measure of performance and/orof profitability may take into account payment that might be due one ormore providers of a feature (e.g., based on its usage).

Referring now to FIG. 9C, an exemplary tabular representation 900Cillustrates another exemplary embodiment of a performance database 445(FIG. 4) that may be stored in computer 400. The tabular representation900C of the performance database includes a number of example records orentries, each defining a trip or visit of a player to a casino. Thoseskilled in the art will understand that the performance database mayinclude any number of entries.

The tabular representation 900C also defines fields for each of theentries or records. The fields specify: (i) a trip identifier 940 thatuniquely identifies a trip or visit of a player to a gamingestablishment (e.g., a casino hotel), (ii) a player identifier 942 thatidentifies the particular player, (iii) a benchmark trip theoretical win946, (iv) a trip theoretical win 948, and (v) a percentage of play withenabled feature(s) 950. Information in this exemplary embodiment may becreated and/or updated as discussed herein with respect to otherdescribed embodiments of the performance database 445.

The trip theoretical win 948 and benchmark trip theoretical win 946 maybe used, in a manner similar to that described above with respect toFIG. 9A, to determine a measure of performance of one or more features.The percentage of play with enabled features 950 may be useful as ameasure of a player's usage of features generally during a trip, indetermining whether or not to change the features enabled for use ongaming devices. In addition, information about how much of the time aplayer plays with one or more features enabled may be useful indetermining what types of features to offer to the player or to makeavailable for selection by the player. For example, a player that tendsto spend more time playing with features enabled may be more willing toaccept an offer to try a feature in exchange for a fee.

Referring now to FIGS. 9D-9E, an exemplary tabular representation 900Dillustrates another exemplary embodiment of a performance database 445(FIG. 4) that may be stored in computer 400. The tabular representation900D of the performance database includes a number of example records orentries, each defining an offer that was made to a player during asession in accordance with one or more active features. Those skilled inthe art will understand that the performance database may include anynumber of entries.

The tabular representation 900D also defines fields for each of theentries or records. The fields specify: (i) a session identifier 960that identifies a session of gaming activity by a player, (ii) a gamingdevice identifier 962 that identifies a gaming device at which the offerwas provided in accordance with one or more features, (iii) a playeridentifier 964 that identifies a player who received the offer, (iv) anoffer 966 that includes an indication (e.g., a description, an offermessage) of the offer provided to the player, (v) an accepted 968 thatindicates whether the offer was accepted, (vi) an active features 970that indicates one or more features that were active when the offer wasprovided, (vii) a cost to offer sponsor 972 that indicates a costincurred by a sponsor of the offer, (viii) a payment to player 974 thatindicates a value of a product, service, or benefit provided to aplayer, (ix) a payment to casino 975 that indicates value provided to acasino operating the gaming device at which the offer was made, and (x)a payment to manufacturer 976 that indicates a value provided to amanufacturer of a gaming device, feature, or game.

Information in this exemplary embodiment may be created and/or updatedas discussed herein with respect to other described embodiments of theperformance database 445. For example, the information may be createdwhen an offer is communicated to a player in accordance with an activefeature.

Some features may enhance play of a gaming device by offering one ormore products or services to a player (e.g., in response to particulargame events, such as the player winning a payout, or the player pushinga “CASH OUT” button). Some such offers may be sponsored by one or moresponsors. For example, FIGS. 9D and 9E depicts an exemplary offer madeto a player “P-568249”: “$30 TO SWITCH LONG DISTANCE TO BIGTEL CO.” Theplayer accepted the offer, which may have been made, in accordance withfeature “FEAT-07”, after a player had wagered a predetermined amount ata slot machine without achieving a winning outcome. The payment toplayer 974 indicates that the amount of $30 was provided to the player(e.g., by increasing the player's credit balance by $30). In addition,$3 was provided in payment to casino 975, and $2 was provided as paymentto manufacturer 976. For example, the sponsor of the offer may have anagreement with the casino that the sponsor will pay the casino a fee(e.g., $3) for each player that accepts its offer. Similarly, thesponsor may agree to pay a $2 to the manufacturer of the feature foreach player that accepts the offer. The cost to offer sponsor 972indicates that the total cost to the sponsor for the accepted offer was$35. Note that the sponsor may value the player, who has agreed toswitch long distance telephone service, in excess of the cost to thesponsor of providing the $35 in benefits and fees to the player andother parties.

Information represented in this exemplary embodiment of the performancedatabase 445 may be used in making various determinations for managingfeatures. In some embodiments of the present invention, a determinationof whether to enable or disable a feature on a gaming device, and/orwhether to offer to activate a feature for a player, may be based on thenumber of offers made in accordance with the feature that have beenaccepted. Thus, the number of accepted offers (or the percentage ofoffers made that were accepted, etc.) may be a useful measure ofperformance and/or usage of the feature. For example, a feature thatprovides offers with a low rate of acceptance may be disabled as it maybe distracting or annoying to players.

Referring now to FIG. 10A, an exemplary tabular representation 1000Aillustrates an exemplary embodiment of a payment database 450 (FIG. 4)that may be stored in computer 400. The tabular representation 1000A ofthe payment database includes a number of example records or entries,each defining a payment made to a provider of a feature. Those skilledin the art will understand that the player database may include anynumber of entries.

The tabular representation 1000A also defines fields for each of theentries or records. The fields specify: (i) a feature identifier 1002that identifies a feature, (ii) a provider 1004 that indicates a partythat provided the feature or otherwise has a proprietary interest in thefeature, and (iii) a payment to provider 1006 that indicates an amountpaid (or to be paid) to the particular provider. Note that one featuremay be associated with two or more providers. For example, feature“FEAT-02” is associated with both “PATENT LICENSOR #1” and “GAMEMANUFACTURER #1”.

As discussed herein, payment to a provider of a feature may bedetermined based on a variety of types of information and measures ofperformance, usage, and/or profitability. In addition, as discussedbelow with respect to FIGS. 10B-10C, payment may be based at least inpart on one or more applicable payment rates.

Referring now to FIGS. 10B and 10C, an exemplary tabular representation100B illustrates an exemplary embodiment of a payment database 450 (FIG.4) that may be stored in computer 400. The tabular representation 1000Bof the payment database includes a number of example records or entries,each defining payment information for a particular feature. Thoseskilled in the art will understand that the player database may includeany number of entries.

The tabular representation 100B also defines fields for each of theentries or records. The fields specify: (i) a feature identifier 1020that uniquely identifies a feature, (ii) a total usage 1022 thatindicates a measure of usage of the particular feature, (iii) a provider1 field 1024 that identifies a party that provided the feature orotherwise has a proprietary interest in the feature, (iv) a provider 1rate 1026 that indicates a rate for use in determining payment forprovider 1, (v) a payment to provider 1 field 1028 that indicates avalue provided (or due) to provider 1, (vi) a provider 2 field 1030 thatidentifies another party that provided the feature or otherwise has aproprietary interest in the feature, (vii) a provider 2 rate 1032 thatindicates a rate for use in determining payment for provider 2, and(viii) a payment to provider 2 field 1034 that indicates a valueprovided (or due) to provider 2. Note that, as in FIG. 10A, one featuremay be associated with two or more providers.

The total usage 1022 indicates information that may be used fordetermining payment due to one or more providers of features, games,and/or gaming devices. Such information may be updated as discussedabove with respect to the exemplary embodiments of the performancedatabase 445. For example, gaming activity may be monitored and updatedon an ongoing basis by one or more of the computer 210, the gamingdevice 230, and/or a peripheral device 240. Examples of measures ofusage appropriate for use with one or more embodiments of the presentinvention include, but are not limited to: (i) a total number of minutesused, (ii) a total revenue generated, (iii) a number of sessions inwhich the feature was enabled or active, (iv) a number of players usingthe feature, and (v) a number of gaming devices at which the feature wasenabled or active. Of course, as discussed variously herein, measures ofusage may also be useful in managing the enablement of features (e.g.,in order to adjust the performance of a feature management system).

The rates 1026 and 1032 depict various exemplary types of rates that maybe used in determining payment to licensors, vendors, and otherproviders, such as per-unit time rates, percentage of revenue rates, feeper user rates, and fee per gaming device rates. Other appropriate typesof rates will be recognized by one of ordinary skill in the art afterreading the present application.

Referring now to FIG. 11, an embodiment 1100 of a plan view of a gamingdevice 230 is illustrated. In the embodiment 1100, the gaming device 230comprises a five reel slot machine. The slot machine 1100 comprises adisplay area 1105 in which an outcome for a game of the slot machine isdisplayed to the player. The display area 1105 may, for example, be avideo display that displays simulations of reels. The display area 1105may, in another example, be glass behind which are located mechanicalreels. Display area 1105 is an exemplary embodiment of the displaydevice 355, described with respect to FIG. 3.

The slot machine 1100 also comprises a display area 1110 in whichinformation about one or more features, such as descriptions offeatures, is displayed to the player. The display area 1110 may, forexample, be a video display that displays images and/or text. Displayarea 1110 is another exemplary embodiment of the display device 355,described with respect to FIG. 3.

The slot machine 1100 further comprises a display area 1118 in whichimages or text indicating available features for play of the slotmachine 110 are displayed to the player. The display area 1118 may, forexample, be a video display that displays images and/or text, and thatmay include a touch screen. Display area 1118 is another exemplaryembodiment of the display device 355, described with respect to FIG. 3.

Slot machine 1100 further comprises a handle 1120. A player may initiatethe movement of the reels in display area 1105 by pulling on the handle1120. Alternatively, a player may initiate the movement of the reels indisplay 1105 by actuating the start button 1125. Either or both ofhandle 1120 and start button 1125 are exemplary embodiments of the inputdevice 365, described with respect to FIG. 3.

Slot machine 1100 also comprises a player tracking device 1130, which isan example of the player tracking device 360 that was described withrespect to FIG. 3. The player tracking device 350 may comprise a playertracking card reader and a display (e.g., an LED display) for outputtinginformation related to the player identifier (e.g., player's name andnumber of comp points associated with player's account).

Also a component of slot machine 1100 is another display area 1135, foroutputting information to a player. The display area 1135 may beutilized, for example, to inform a player of which features arecurrently active on the slot machine 1100 and/or may provide a way forthe player to deactivate an active feature. The display area 1135 may,for example, be a video display including a touch screen. Display area1135 is another exemplary embodiment of the display device 355,described with respect to FIG. 3.

Payment system 1140, an exemplary embodiment of payment system 375,comprises a bill acceptor and/or a credit card reader 1150, and a coinacceptor 1155. A player may utilize payment system 1140 to provide awager for playing a game and/or for providing payment for provision of afeature available on slot machine 1100.

Slot machine 1100 further comprises a credit meter balance 1160, whichis an exemplary embodiment of a benefit output device 350 that wasdescribed with respect to FIG. 3. The credit meter balance reflects theamount of electronic credits currently available to a player. Theelectronic credits may be used by a player, for example, as wagers forgames played on the gaming device. The electronic credits may also be“cashed out” as coins, bills, tokens, a cashless gaming receipt, and/orcredits to another financial account associated with the player.

The slot machine 1100 includes yet another display area, display area1165, which displays a payout schedule of the slot machine 1100. Thepayout schedule displays payouts that correspond to various outcomesobtainable on the slot machine 1100. In one or more embodiments, if anoutcome is displayed in display area 1105 that, as indicated in displayarea 1165, corresponds to a payout, the credit meter balance 1160 may beincreased by an amount of electronic credits corresponding to thepayout.

Finally, the slot machine 1100 comprises a coin tray 1170. Payment tothe player may be rendered by dispensing coins into the coin tray 1170.Such coins may be dispensed based on, for example, a player's indicationthat the player would like to cash out his credit meter balance and/or apayout obtained by a player as a result of playing a game on the slotmachine 1100. The coin tray 1100 is an exemplary embodiment of thebenefit output device 350, described with respect to FIG. 3. Note thatslot machine 1100 may include different and/or additional componentsbesides those illustrated in FIG. 11.

Referring now to FIG. 12, a flowchart illustrates a process 1200 that isconsistent with one or more embodiments of the present invention. Theprocess 1200 is a method for determining a payment based on a measure ofperformance, in which the measure of performance involves determining adifference between two measures of usage for one or more gaming devices.For illustrative purposes only, the process 1200 is described asutilizing an amount of revenue generated as the measure of usage. Ofcourse, the process 1200 may be adjusted for any type of measure ofusage (e.g., an amount wagered, a number of product/service offersaccepted, a theoretical win, etc.). Also for illustrative purposes only,the process 1200 is described as being performed by a slot server. Ofcourse, the process 1200 may be performed by a gaming device 230 and/ora computer 210.

In step 1205 the slot server determines a feature that has been activeon at least one gaming device. For example the slot sever looks upinformation stored in the gaming device 435 and/or the performancedatabase 445 and identifies a feature that has been in use of one ormore gaming devices. In step 1210, the slot server determines an amountof revenue generated at the at least one gaming device while the featurewas active. For example, by reference to a performance database thatstores indications of use of features by session, as in tabularrepresentation 900A (FIG. 9A), the slot server could determine the totalcoin-in 910 and the active features 916 for each session. For instance,in “SESS-01”, a total of “345.00” was received while “FEAT-02” wasactive.

In step 1215, the slot server determines a benchmark amount of revenue.The second amount of revenue may be revenue generated at the at leastone gaming device, may have been generated at one or more other gamingdevices, or may be some other amount being used as benchmark. Forexample, the slot server may determine that the benchmark amount ofrevenue is equal to a revenue projection for the at least one gamingdevice.

In step 1220, the slot server determines a difference between the amountof revenue generated while the feature was active and the benchmarkamount. In other words, the slot server compares the two amounts todetermine a measure of performance of the feature. For example, if thebenchmark amount is less than the amount of revenue generated, thedifference by which the revenue exceeded the benchmark value may becorrelated to the use of the feature on the at least one gaming device.

In step 1225, the slot server determines a payment rate that isassociated with a party (e.g., a proprietor or other provider of thefeature) and in step 1230 determines a payment amount based on thepayment rate and the difference between the amount of revenue generatedand the benchmark amount. For example, the slot server looks up theappropriate payment rate for the feature in payment database 450. Forinstance, the payment rate may be a flat rate payable only if thebenchmark is exceeded. In another example, the payment rate may be basedon the amount of the difference, such as a percentage (e.g., 5%) of thedifference. In step 1235, the slot server initiates payment of thepayment amount to the party. For example, the slot server may send anencrypted indication of the usage statistics to the party, and the partymay confirm the amounts and bill the casino. Methods of encrypting usagestatistics and other data for transmission to the party are described indetail below. In another example, the slot server may provide payment(e.g., via an electronic funds transfer).

It should be noted that, similar to the determinations in process 100B,process 1200 may further include a determination of whether the featureshould remain enabled on one or more gaming devices. Such adetermination may be based, for example, on a determination of whether apredetermined condition has been satisfied (e.g., whether the differenceis greater than a predetermined increase in revenue). Such apredetermined condition may comprise a condition similar to thosedescribed with respect to step 165 of process 100D.

According to some alternative embodiments of the present invention,systems and methods for managing features, determining measures ofperformance of features and devices, and/or determining payment owed toproprietors and providers of features and devices may be applied toindustries other than gaming, such as the industries for vendingmachines and other point-of-sale terminals.

According to various embodiments of the present invention, a provider ofa feature, gaming device and/or game (e.g., a trademark holder, a gamemanufacturer, a controller) may provide an indication of at least oneauthorization code (e.g. to a sever computer, to a gaming device). Theauthorization code may be used in determining whether to enable ordisable one or more features (e.g., of one or more games, of one or moregaming devices, of one or more gaming systems).

An authorization code (e.g., a password, an access code, a featurecontrol authentication code) may comprise any of various types ofinformation suitable for indicating that an entity having the code(e.g., a slot server, a slot machine) is permitted to enable and/ordisable a feature. For example, an authorization code may comprise,without limitation, one or more alphanumeric characters, a sequence ofdigits, a digital certificate, and/or a combination thereof. In somealternative embodiments, the authorization code may comprise all or aportion of a program for using, enabling, and/or disabling the feature.

According to some embodiments, an authorization code may be indicated toa server computer (e.g., a slot machine server). For example, anemployee of a casino may input an authorization code when prompted by aslot server in accordance with a program for managing features in a slotmachine network. The controller (and/or the employee) may then bepermitted to enable or disable one or more features in accordance withthe authorization code (e.g. based on a stored condition for enabling afeature). Alternatively, or in addition, an indication of anauthorization code may be provided to a gaming device. The gaming devicemay then enable or disable features as appropriate.

An authorization code may be provided by any one or more of a variety ofdifferent parties. For example, a casino (e.g., a representative of acasino, such as a slot host, system administrator, or other employee)may provide an authorization code (e.g. to a slot server, to a gamingdevice). In another example, a regulatory body or group (e.g., a state,federal, or local government regulating agency; an industry regulatoryor standardization group) may provide an authorization code for afeature. For example, if a state regulatory agency does not approve of afeature, then it may refuse to issue an authorization code for thefeature, thereby preventing the feature from being enabled on gamingdevices. Alternatively, the agency may issue an authorization code thatdisables a previously-enabled feature.

In another example, the state regulatory agency may mandate that aparticular feature be enabled, and may issue a correspondingauthorization code. A proprietor of a feature (e.g., a gamemanufacturer, a patent holder) may provide an authorization code. Forexample, a game manufacturer may sell authorization codes for aparticular feature. In another example, in order to enable apre-installed feature (e.g. a program including instructions forproviding the feature was previously provided to a casino) on a gamingdevice, a casino can purchase the appropriate authorization code fromthe game manufacturer.

According to some embodiments, an authorization code may be generated ina manner so as to prevent, discourage, or make computationallyunfeasible forgery of authorization codes (e.g., using cryptographictechniques). An authorization code may be generated by a trusted thirdparty. For example, a proprietor may request that a third party generatean authorization code. The third party may generate the code andtransmit the code to the requesting party. Alternatively, or inaddition, the third party may transmit the authorization code to acontroller, a player, or a gaming device for use in accordance withvarious embodiments of the present invention.

According to some embodiments of the present invention, it may bedifficult or impossible to enable a feature of a game or a gaming devicewithout an authorization code. For example, a casino may not be able toenable a particular feature unless an authorization code has beenreceived (e.g., from a proprietor of the feature). In another example, agaming device may not be able to provide for a feature unless theauthorization code has been provided to the gaming device (e.g., by acontroller, by a game manufacturer). Similarly, according to someembodiments, it may be difficult or impossible to disable a feature of agame or a gaming device without a corresponding authorization code.

In one or more embodiments, an authorization code may enable a featureand prevent subsequent disabling of the feature (e.g., for apredetermined minimum number of uses of the feature). Similarly, in someembodiments an authorization code may disable a feature and preventenabling of the feature (e.g., for a period of time).

In one or more exemplary embodiments for enabling a feature, theauthorization code provides a processor or operator of a gaming systemwith access to a file, storage device, program, and/or program modulethat is necessary to enable or disable a feature. For example, in amanner known in the art, a program for providing one or more features ina gaming system may require that an operator of the system provide anappropriate authorization code (e.g., a password, an access code) beforeallowing a feature to be enabled. One or more authorization codes may bestored, for example, in feature database 425 (FIG. 4). According to someembodiments of the present invention, an authorization code may berequired in order to add, delete, or modify one or more conditions forenabling and/or disabling a feature.

A condition for whether to enable and/or disable a feature may berelated to one or more authorization codes. In some exemplaryembodiments, a condition for enabling a feature may require that one ormore authorization codes have been provided. For example, in order for acasino to enable a “Jackpot Only” feature on its slot machine network,the casino may have to acquire one authorization code from the owner ofa patent for “Jackpot Only” and another authorization code from themanufacturer of the casino's slot machines at which “Jackpot Only” canbe enabled. Accordingly, to enable the “Jackpot Only” feature, the slotnetwork controller determines whether or not the two authorization codeshave been received (i.e. whether the exemplary condition for enabling“Jackpot Only” is satisfied).

According to some embodiments, a plurality of authorization codes may berequired to enable a feature. For example, a feature on a gaming devicemay only be enabled if a first authorization code is provided by a firstparty (e.g. a regulator) and a second authorization code is provided bya second party (e.g., a proprietor). Alternatively, an authorizationcode may comprise multiple parts that may be provided by multipleparties. Of course, a plurality of authorization codes (or parts of anauthorization code) may be provided by one party rather than multipleparties.

In some exemplary embodiments, whether or not a feature may be enabledand/or disabled may be based on a period of time since an authorizationcode was provided. For example, the authorization code may have anassociated period of validity (e.g., thirty days after providing of theauthorization code, thirty days after a corresponding feature is enabledor disabled). After the associated period of time (e.g., when theauthorization code “expires”), a controller, for example, may beprevented from enabling and/or disabling a feature. Thus, a casino maybe allowed by a proprietor (or a regulatory body, etc.) to enable afeature for only a limited period of time. Conversely, a casino may beprevented by a proprietor of a feature from disabling the feature untilafter the feature is used for a minimum period of time. In someembodiments, a new authorization code must be provided after (or before)the period of time in order to allow for enabling and/or disabling ofthe feature (e.g., by a controller, by a gaming device). Alternatively,or in addition, an authorization code may have an expiration date afterwhich the authorization code is no longer valid for enabling and/ordisabling one or more features.

In other exemplary embodiments, whether or not a feature may be enabledand/or disabled may be based on an amount of use of a feature (e.g.,since an authorization code was provided, since a corresponding featurewas enabled or disabled). For example, the authorization code may beassociated with a number of uses of a feature (e.g., 500 uses by agaming system, 5 uses by a player, 200 uses by a gaming device). Thus, acasino may be allowed to enable a feature for only a limited period oftime based on the provided authorization code. Conversely, a casino maybe prevented from disabling an enabled feature until the feature hasbeen used a minimum number of times. Of course, usage of a feature maybe measured in various ways other than a number of uses, as discussedherein. For example, an authorization code may expire after anassociated total wager amount in games using the feature.

According to one or more embodiments of the present invention, a featuremay be automatically disabled or enabled if an authorization code is notprovided in accordance with various criteria. Examples of predeterminedconditions that must be satisfied for automatically disabling orenabling a feature include, but are not limited to:

-   -   (i) requiring that an authorization code be entered every thirty        days to keep a feature enabled on a gaming device;    -   (ii) requiring that an authorization code be entered every two        hundred thousand spins to keep a feature enabled for a slot        machine game; and    -   (iii) requiring that an authorization code be provided in order        to disable at a gaming device a feature for automatically        displaying advertisements.

A feature may be associated with more than one authorization code (ortype of authorization code). For example, one authorization code mayallow a casino to enable a feature for thirty days at a first type ofgaming device at any time of day, and a different authorization code maypermit a casino to enable the same feature for a year at a differenttype of gaming device only during peak hours. Accordingly, determiningwhether a condition for enabling and/or disabling a feature is satisfiedmay include determining the type of authorization code provided.

An authorization code in accordance with various embodiments of thepresent invention may allow for enabling and/or disabling of: (i)multiple (or all) features for multiple (or all) games on multiple (orall) gaming devices; (ii) multiple (or all) features for multiple (orall) games on one gaming device (e.g. a different code is needed for adifferent gaming device, an authorization code is associated with aparticular gaming device); (iii) multiple (or all) features for one gameon multiple (or all) gaming devices (e.g., a different code is neededfor a different game, an authorization code is associated with only onegame); (iv) multiple (or all) features for one game on one gaming device(e.g., a different code is needed for a different game on the samegaming device, or for the same game on a different gaming device; anauthorization code is associated with only one gaming device and withonly one game); (v) one feature for multiple (or all) games on multiple(or all) gaming devices (e.g., a different code is needed for adifferent feature, an authorization code is associated with only onefeature); (vi) one feature for multiple (or all) games on one gamingdevice (e.g., a different code is needed for a different feature on thesame gaming device, or for the same feature on a different gamingdevice; an authorization code is associated with only one feature andwith only one gaming device); (vii) one feature for one game on multiple(or all) gaming devices (e.g., a different code is needed for adifferent feature in the same game, or for the same feature in adifferent game; an authorization code is associated with only onefeature and with only one game); and (viii) one feature for one game onone gaming device (e.g., a different code is needed for every singlefeature on every single game on every single gaming device, anauthorization code is associated with only one feature and with only onegame and with only one gaming device).

Thus, according to one exemplary embodiment of the present invention,one or more authorization codes may be used to enable or disable only asingle feature on only a single gaming device. Thus, an additionalauthorization code (or codes) may be necessary to enable or disable adifferent feature on the same gaming device, and an additionalauthorization code (or codes) may be necessary to enable or disable thesame feature on a different gaming device. Such an embodiment wouldprevent a casino, for example, from using the same authorization code toenable the same feature on multiple gaming devices and/or to enablemultiple features on one or more gaming devices.

Some embodiments of the present invention permit an interested party toverify usage data relating to a game machine and know that an “attacker”has not misrepresented this usage data. According to some embodiments,the invention may provide the following benefits: data legitimacy (i.e.,knowing that usage data is based on usage of a game machine. Forexample, an authentication code may authenticate that an attacker didnot simply fabricate data relating to usage of a game machine); datapaternity (i.e., knowing where usage data comes from. For example anauthentication code may authenticate that usage data was generated by aspecific game machine, a specific type of game machine, or a gamemachine from a specific group); data integrity (i.e., knowing that usagedata has not been tampered with or modified in any manner. For example,an attacker may attempt to modify usage data to reduce a payment that itowes to a game manufacturer); data temporality (i.e. knowing that usagedata corresponds to activities during a given time. For example, timestamping a feature activation time); game machine integrity (i.e.knowing that a game machine has not been tampered with or modified inany manner. For example an attacker may attempt to modify a game machineto change the way an authentication code is generated or determine asecret key stored in the game machine); transmission integrity (i.e.,knowing that usage data or an authentication code has not been modifiedduring transmission, either accidentally or intentionally. Differentmethods of transmitting an authentication code from a game machine to anauthentication server are described in detail below); andnon-repudiation (i.e., preventing a party from denying that it providedan input. For example, an attacker may attempt to deny that he chose toenable a feature on a game machine).

According to some embodiments, data regarding usage of a game machinemay be verified for an interested party. An interested party may be aparty that is interested in knowing that usage data relating to gamemachine is authentic.

Examples of Interested Parties Include:

-   -   (i) regulatory groups (e.g., state government)—For example, a        state government may be interested in verifying that a casino is        paying the appropriate taxes for game machines that it operates.    -   (ii) licensors (e.g. patent, trademark, and/or copyright        holders)—For example, a licensor may be interested in verifying        that a casino is paying the appropriate licensing fees for a        trademark, patent, or copyright.    -   (iii) game manufacturers—For example, a game manufacturer may        lease a game machine to a casino for a percentage of revenues        generated by the game machine. The game manufacturer may be        interested in verifying the revenues generated by the game        machine to ensure that the casino provides the correct lease        payments.    -   (iv) subsidizers or sponsors (e.g., credit card companies,        consumer product manufacturers, retailers)—For example, a game        machine may present offers or advertisements to players. A        subsidizer or sponsor may pay a fee based on offers presented,        advertisements viewed, or offers accepted by a player. The        subsidizer may be interested in verifying that it is not being        overcharged.    -   (v) casino—For example, a game machine may be a portable device        that a player may take out a casino. The casino may wish to        verify that the player did not tamper with the game machine in        any way.    -   (vi) player—For example, a player may wish to prove his usage of        a game machine to obtain a benefit as part of a non-networked        comp system.

Note that as discussed in detail above, according to some embodiments, acasino may provide consideration to an interested party based on usagedata and an interested party may provide consideration to a casino basedon usage data. Note also that it is possible for a party (e.g., acasino) to be both an interested party and an attacker.

Various parties may be interested in misrepresenting usage data from agame machine and thereby deceiving one or more interested parties. Forclarity, the term “attacker” is used to refer to any party that mayattempt to tamper with, forge, hide, or otherwise misrepresent usagedata from a game machine. Examples of attackers include disreputablecasinos, untrustworthy or error prone casino employees, and/or players.Casinos may include any party that owns or leases a gaming device andenables a player to play games on the gaming device.

Examples of a Casino as an Attacker Include:

-   -   (i) A casino employee may inadvertently misrepresent usage data        that is reported to a regulatory group. For example, a casino        may unintentionally overstate the revenues from a game machine,        thereby unnecessarily increasing its taxes due to a tax        collector.    -   (ii) A casino employee may misrepresent usage data that is        reported to a licensor. For example, a casino may understate the        usage of a patented feature on a game machine, thereby reducing        a licensing fee that it owes to the holder of a patent on the        patented feature.    -   (iii) A casino employee may misrepresent usage data that is        reported to a game manufacturer. For example, in an effort to        qualify for a personal bonus, a casino employee may overstate        the revenues from a game machine to make it appear that the        gaming activity associated with him as a host is larger than it        actually is. The end result is that not only has the employee        cheated the casino, but the fee owed to the game manufacturer is        inflated.    -   (iv) A casino employee may misrepresent usage data that is        reported to a third-party subsidizer. For example, a casino may        unintentionally overstate the number of advertisements displayed        on a game machine and erroneously attempt to overcharge the        advertiser for displaying the advertisements.

Examples of a Player as an Attacker Include:

-   -   (i) A player may misrepresent usage data relating to comps. For        example, a player may overstate his usage of a game machine        (e.g., a portable game machine), thereby entitling himself to        more comps from a casino.    -   (ii) A player may misrepresent usage data relating to outcomes.        For example, a player may overstate his winnings or understate        his losses achieved at a game machine (e.g., a portable game        machine, or a game machine that player has tampered with or        stolen money out of), thereby defrauding one or more parties        associated with the game machine (e.g. a casino, a game        manufacturer, a regulatory group).    -   (iii) A player may misrepresent usage data relating to features.        For example, a player may claim that he did not activate a        feature on a game machine, thereby avoiding the affects of the        feature, or paying a fee to an interested party (e.g., a casino)        based on usage of the feature.    -   (iv) A player may misrepresent usage data relating to location.        For example, a player may hide the fact that he used a portable        game machine in a state where they are prohibited, thereby        avoiding being arrested and/or fined.    -   (v) A player may tamper with a game machine. For example, a        player at a casino may alter a game machine so that it produces        one or more winning outcomes.

Note that an attacker (e.g. a player) may cheat or otherwise attack anauthentication system in a variety of different ways. According tovarious embodiments, the invention may prevent some or all of thefollowing attacks:

-   -   (i) Usage data may be miscommunicated to an interested party.        For example, two subsidizers may agree to pay a casino $0.25 for        each promotional offer that is presented to a player at a game        machine. During the course of a month, the game machine may        present 300 promotional offers to players from the first        subsidizer and 100 from the second. However, the casino might        unintentionally report to the first subsidizer that only 100        promotional offers were presented to players and report to the        second subsidizer that 300 of their offers were presented. The        present invention helps avoid any confusion as to the number of        offers presented and to whom.    -   (ii) An attacker may attempt to reuse usage data from a previous        time period. For example, a casino employee may record the usage        data for May 2001 (e.g., a month with low revenues) and then        claim that this usage data corresponds to June 2002, thereby        reducing the claimed revenues for June 2002. Without the present        invention, an interested party (e.g. a licensor) may have no way        of knowing that it had received incorrect data.    -   (iii) An attacker may attempt to reuse usage data on a second        game machine. For example, a first game machine (e.g., one that        generates few revenues) may generate usage data for May 2002.        This usage data may be transmitted to the authentication server        in an appropriate manner. However, the casino employee may claim        that this usage data also corresponds to a second game machine        for May 2002 (e.g., one that in fact generated greater        revenues), thereby reducing the claimed revenues for the second        game machine. Without the present invention, an interested party        (e.g. a game machine manufacturer) may have no way of        authenticating the temporality and/or reuse of usage data.    -   (iv) A attacker may attempt to switch usage data between two or        more game machines. For example, a first game machine (e.g., one        with a high percentage of revenues as a license fee) may        generate a first set of usage data (e.g., corresponding to high        revenues) and a second game machine (e.g., one with a low        percentage of revenues as a license fee) may generate a second        set of usage data (e.g., corresponding to low revenues). A        casino employee may inadvertently report that the first set of        usage data corresponds to the first game machine and the second        set of usage data corresponds to the second game machine,        thereby reducing its total license fees. Without the present        invention, an interested party (e.g., a game machine        manufacturer) may have no way of authenticating the source of        the usage data.    -   (v) An attacker may deny that it enabled or disabled a game        machine or a feature on a game machine. For example, a route        operator (i.e. a business that manages multiple game machines at        multiple locations often for multiple gaming device owners) may        pay a fee to a game manufacturer for each feature that it        enables on a game machine. Without the invention, a route        operator might enable a feature and then claim that this feature        was not enabled. Similarly, a route operator may claim that a        game machine activated a feature without the permission of the        route operator. Using a combination of activation codes        (discussed above) and authentication codes, the present        invention may clarify that only the route operator could have        activated the feature.    -   (vi) An attacker (e.g. a player) may tamper with a game machine        (e.g., by modifying the software or hardware of the game        machine). For example, a player may attempt to modify a game        machine to change a payout table. According to various        embodiments, the present invention may prevent such an attacker        from modifying a game machine or alert a casino or interested        party if a game machine has been modified.

In addition, the present invention may prevent accounting errorsrelating to tracking usage data. For example, usage data may beaccidentally miscommunicated to an interested party. For example, whencopying usage about a game machine, a casino employee may accidentallymistake a “7” for a “1”, thereby reducing a license fee from $7000 to$1000. Using authentication codes, the invention may allow a system toidentify and correct this error. In another example, a transmissionerror may cause usage data to be modified. For example, a packet of datamay be modified during transmission from a game machine to anauthentication server. Using authentication codes, the invention mayallow a system to identify and correct this error. Note that many otherattacks are also possible.

Turning to FIGS. 13A and 13B, block diagrams of other examples of agaming device 1300 according to some embodiments of the presentinvention are provided. The gaming devices 1300 depicted includefeatures to support embodiments that including outputting authenticationcodes that allow interested parties to verify usage data. As indicatedabove, examples of such gaming devices 1300 may include slot machines(e.g., located in a casino or on a riverboat), video poker terminals,video lottery terminals, pachinko machines, table-top games (e.g.,located in a bar or other commercial establishment), personal computers(e.g. to communicate with website that provides gambling services),telephones (e.g., to communicate with an automated sports book thatprovides gambling services), portable gaming devices (e.g., a personaldigital assistant, a laptop computer, or Nintendo® GameBoy®), and inembodiments of the present invention addressing table game play such asblackjack, craps, roulette, poker, baccarat, keno, bingo, and the like,the gaming device may include hardware (e.g., a table-top box) locatedat the game table suitable for tracking events at the game table. Theembodiments shown in FIGS. 13A and 13B include a processor 1302, memory1314, a secret key 1316, a secure perimeter (not shown), a random numbergenerator 1318 (e.g., to generate random or pseudo-random outcomes), acommunication port 1320 (e.g., to communicate with a casino server orauthentication server), at least one input device 1322, at least oneoutput device 1324, a payment system 1326 (1326A to 1326H in FIG. 13B),a data storage device 1304, and a clock (not shown). As illustrated inFIG. 13B, a gaming device 1300 such as a reeled slot machine will alsoinclude a reel controller 1328 and one or more reels 1328A to 1328C.

As with other embodiments described above, the processor 1302, alsoreferred to as a microprocessor, “CPU” or “central processing unit,” issuitable for executing instructions and performing processes of theinvention. For example, a gaming device 1300 may include an Intel®Pentium 4® microprocessor. According to some embodiments, a gamingdevice 1300 may include a plurality of processors. For example, a gamingdevice 1300 may include a first processor for executing operationsrelating to game play and a second processor for performingcryptographic functions relating to authenticating usage data.

Note that in some embodiments a player may operate multiple gamingdevices. For example, a player may simultaneously play two side-by-sidegaming devices, a player may play a gaming device and then continue hisgambling session at a video poker machine, and/or a player may use atelephone or other device to remotely operate a gaming device. Accordingto various embodiments, a gaming device may enable a player to play avariety of different types of games. Notable embodiments of differenttypes of games include a game of chance (e.g. a slot machine, videopoker, pachinko, blackjack); a game of skill (e.g., skill crane,skee-ball, a video game which may be more appealing to certain playersor may be permitted in areas where it is illegal to gamble on games ofchance); a game that provides a prize; a game that has an entry fee;and/or a game that is a combination of any of these types.

Output devices 1324 include devices that may be used to outputinformation from a gaming device (e.g., to a player). Examples of outputdevices include: a video monitor, a light-emitting diode (LED), an audiospeaker, an electric motor, a printer, a coupon or product dispenser, aninfra-red port (e.g., for communicating with a second slot machine), aBraille computer monitor, a coin or bill dispenser, a floppy disk drive,a compact disc burner. For gaming devices, examples of common outputdevices include a cathode ray tube (CRT) monitor on a video pokermachine, reels on a slot machine, a bell on a slot machine (e.g. ringswhen a player wins), an LED display of a player's credit balance on aslot machine, an LCD display of a personal digital assistant (PDA) fordisplaying keno numbers, and a printer to provide a receipt for aplayer's gambling credits. An output device may output informationrelating to game play, as is known to those skilled in the art. Anoutput device 1324 may output an authentication code, as describedbelow.

Input Devices 1322 include devices that may be used to receive an input(e.g., from a player). Examples of input devices 1322 include a “spin”button, a coin or bill acceptor, a lever on a slot machine, a touchscreen (e.g., on a video poker machine), a magnetic stripe reader (e.g.to read a player tracking card), a computer keyboard, a computer mouse,microphone (note that a microphone may be part of, or be otherwiseassociated with a voice recognition module), a video camera, biometricinput device (e.g., a fingerprint reader, a camera with facialrecognition capability, a retinal scanner, a DNA sequencer), a radioantenna (e.g., for receiving inputs from a second slot machine), aposition sensor (see details below), a voice recognition module, voltagesensor (e.g., some touch screens use voltage sensors to determine wherea user touches the screen), current sensor (e.g., some touch screens usecurrent sensors to determine where a user touches the screen), and aweight sensor (e.g., to determine how many coins are in the hopper of agaming device).

According to some embodiments, a gaming device 1300 may include aposition sensor suitable for determining a location of the gamingdevice. Examples of position sensors include a GPS (global positioningsystem) device, a radio beacon, a cellular telephone (note that the FCChas mandated that all cellular telephones include Automatic LocationIdentification (ALI) by January 2006), an inertial measurement unit(IMU) (e.g. an inertial measurement unit may include a plurality ofgyroscopes and accelerometers and, by using measurements from thesesensors, it may be possible to determine the position of the gamingdevice), and/or a dead-reckoning system (e.g., a gaming device may belocated in an automobile. By tracking the distance and directiontraveled by the automobile, it may be possible to determine the locationof the automobile). It may be particularly useful to include a positionsensor in a gaming device that is portable. For example, a gaming devicemay be a laptop computer, a tablet computer, a personal digitalassistant, or a handheld gaming device (e.g., a Gameboy®).

A gaming device 1300 may include a payment system 1326 that performs twomain functions, accepting payment from a player (e.g., a bet) andproviding payment to a player (e.g., a prize). It should be noted thatpayment is not limited to money but may also include other types ofconsideration, including products, services, and alternate currencies(e.g., casino chips). Exemplary methods of accepting payment from aplayer include receiving hard currency (i.e., coins or bills via a coinor bill acceptor), receiving an alternate currency (e.g., a papercashless gaming voucher, a coupon, a casino token), receiving a paymentidentifier (e.g., a credit card number, a debit card number, a playertracking card number wherein the account identified by the paymentidentifier may then be debited accordingly), and/or determining that aplayer has performed a value-added activity.

Exemplary methods of providing payment to a player include dispensinghard currency (i.e., coins or bills), dispensing an alternate currency(e.g., a paper cashless gaming voucher, a coupon, a casino token),crediting a player account (e.g., a bank account or other financialaccount identified by a payment identifier such as a credit card number,a debit card number, and/or a player tracking card number), and/orproviding a product or service to the player (e.g., a jackpot prize maybe a new car).

According to some embodiments, a gaming device may store a secret key1316. This secret key 1316 may be used for a variety of purposesrelating to encryption, including encrypting authentication codes,encrypting usage data, encrypting information that is stored on a datastorage device, decrypting information that is stored on a data storagedevice, decrypting messages from an authentication server, andencrypting messages to send to an authentication server. A variety ofdifferent types of secret keys 1316 are possible, depending on what typeof encryption is employed by the gaming device 1300. Examples include akey for a symmetric encryption algorithm, a private key for a public-keyencryption algorithm (a public key for a gaming device may be publishedthrough an authentication server), and/or a one-time pad. Differenttypes of encryption are discussed in detail below.

A secret key 1316 may be generated or stored in a gaming device's memory1314 in a variety of different ways, including:

-   -   (i) A secret key 1316 may be generated and stored in a gaming        device when the gaming device is manufactured. For example, a        gaming device manufacturer may generate a secret key 1316 and        store this secret key in a ROM on a gaming device 1300. A        duplicate copy of this secret key 1316 may be stored on an        authentication server.    -   (ii) A secret key 1316 may be indicated to a gaming device 1300        using an input device 1322 or communication port 1320. For        example, an employee of a casino or a gaming device manufacturer        may use a numeric keypad to enter a secret key 1316 into a        gaming device 1300.    -   (iii) A gaming device 1300 may generate its own secret key 1316.        For example, a gaming device 1300 may generate a public        key/private key pair for use in public key encryption. The        gaming device 1300 may store the private key in memory as a        secret key 1316, and output the public key for use by one or        more interested parties.        Note that a secret key 1316 may be stored in a variety of        different types of memory or data storage devices. Note that a        secret key 1316 may be stored in a separate memory bank from a        gaming device's random access memory. For example, a secret key        1316 may be stored in read-only memory in a gaming device's        processor. According to some embodiments, a secret key 1316 may        be protected by a secure perimeter. See below for details about        secure perimeters. According to some embodiments, an attempt to        access the key 1316 may result in the key being erased or        destroyed. According to some embodiments, the same secret key        1316 may be used for a plurality of gaming devices. This may        make it more convenient to manufacture gaming devices or decrypt        authentication codes generated by gaming devices. However, note        that if this secret key 1316 is compromised on one gaming        device, then all the gaming devices that share the secret key        may be compromised. Using a different secret key 1316 for each        gaming device helps to avoid this risk. According to some        embodiments, a secret key 1316 for a gaming device may be kept        secret from at least one party (e.g. a casino) to prevent the        party from tampering with one or more authentication codes        generated by the gaming device.

According to some embodiments, a gaming device 1300 may include a secureperimeter (not shown). According to some embodiments, a secure perimetermay be a defined physical area of hardware which is tamper-resistantand/or temper-evident, in which resides data or algorithms whosecharacteristics must not be alterable in order for a system to remainsecure. According to some embodiments, a secure perimeter may protect anentire gaming device. Alternatively, the secure perimeter may protectonly a portion of the gaming device 1300, for example a secret key 1316of the gaming device 1300; the processor 1302, memory 1314, and a secretkey 1316; the processor 1302 of the gaming device 1300; the processor1302 and memory 1314 of the gaming device 1300; the processor 1302,memory 1314, and data storage device 1306 of the gaming device 1300;and/or the processor 1302, memory 1314, and clock of the gaming device1300.

A secure perimeter may help to prevent an attacker (e.g. a casinoemployee) from performing various activities that may compromise theobjectives of the invention, including reading or determininginformation (e.g. a secret key 1316, or information stored in a database1308, 1310, 1312); removing, adding, or otherwise altering data that istracked by a gaming device 1300; altering a portion of a program 1306that is run by a gaming device 1300; altering the hardware of a gamingdevice 1300; and/or altering an authentication code generated by agaming device.

According to some embodiments, a secure perimeter may make at least aportion of the gaming device 1300 tamper-resistant. Tamper-resistanthardware or software may be difficult to modify or alter from itsintended purpose. In some cases, attempts to alter such hardware orsoftware will render the hardware or software inoperable. Examples oftamper-resistance include input/output pins of a computer chip may beelectrically isolated to prevent pin-level probes; a computer chip maycontain mechanical and/or chemical protection to prevent chip-probingequipment from accessing information in the chip; and/or if a gamingdevice is tampered with, then encryption keys and other data may beerased from memory. According to some embodiments, a secure perimetermay make at least a portion of the gaming device tamper-evident.Tamper-evident hardware or software may show, upon inspection orinterrogation, evidence of any attempt or success at the modification oralteration of its intended purpose or stored data.

Examples of devices which incorporate secure perimeters include U.S.military encryption devices such as the STU-III telephone made byMotorola and AT&T, and the iPower card, available from NationalSemiconductor Corp. According to some embodiments, a gaming device mayinclude multiple secure perimeters. For example, a first secureperimeter may surround a gaming device's CPU and a second secureperimeter may protect a data storage device of the gaming device. Notethat a secure perimeter is not shown in FIG. 13A or 13B.

As discussed above, a gaming device 1300 may include volatile ornon-volatile memory, or a combination thereof. This memory may beelectronic, capacitive, inductive, or magnetic in nature. Examples ofmemory include: RAM (random access memory), ROM (read-only memory).Memory may be used for storing information such as program instructions,encryption keys (e.g. a secret key), authentication codes, and/oractivation codes.

As shown in FIGS. 13A and 13B, a gaming device 1300 may also include adata storage device 1304. According to some embodiments, this datastorage device 1304 may store a program 1306, an event database 1308, agame data database 1310, and/or an authentication code database 1312.

Turning to FIG. 14, an embodiment of an event database 1308 is depicted.According to some embodiments, an event database 1308 may store a listof events that occur at a gaming device 1300. For example, theparticular embodiment depicted stores the time of the event 1400, aplayer identifier 1402, and a description of the event 1404. Many otherdetails regarding events may be tracked and the three chosen merelyrepresent an example of the types of information that may be stored.Likewise, each row of the event database 1308 provides an example entry.For example, the second row indicates that a $20 bill was inserted intothe gaming device 1300 at 3:45 PM on May 5, 2002 by a player with IDnumber PLAY-1-89403125.

Turning to FIG. 15, an example embodiment of a game data database 1310is depicted. According to some embodiments, the game data database 1310may store descriptions of data 1500 and values 1502 of information aboutusage of the gaming device 1300. For example, the particular exampleembodiment depicted stores total coin-in 1504; average coin-in persession 1506; number of offers presented 1508; percentage of offersaccepted 1510; average revenue per hour 1512; total theoretical win1514; percentage of game sessions longer than three hours 1516; and thetotal time that 3D graphics mode was used 1518. Details regarding theseand other statistics that may be tracked in the game data database 1310are described below. Note that offers presented and accepted refers togaming device features that actually cause the gaming device to presentoffers to, and receive acceptances from, players.

Turning to FIG. 16, an example embodiment of an authentication codedatabase 1312 is depicted. According to some embodiments, anauthentication code database 1312 may store authentication codes andinformation that may be used in determining authentication codes. Forexample, for each entry, the particular example embodiment depictedstores a time 1600; a year-to-date coin-in 1602; the number of creditcard offers presented since last update 1604; and an authentication code1606. Note that the authentication code database 1312 may storeinformation similar to that which is stored in the game data database1310 (e.g., year-to-date coin in, and revenues since last update in thisexample).

According to some embodiments, some or all information stored on a datastorage device 1304 may be encrypted (e.g. using a secret key 1316). Forexample, a program may be encrypted to prevent an attacker fromtampering with the program and altering the operation of a gamingdevice, and/or an event database may be encrypted to prevent an attackerfrom altering stored information about usage of a gaming device.According to some embodiments, information on a data storage device 1304that is encrypted may only be encrypted or decrypted using a secret key1316, such as the type described above. According to some embodiments, adata storage device 1304 may be protected by a secure perimeter asdescribed above.

As described above, the system of the present invention may include atleast one communication network to enable communication between a gamingdevice 1300 and at least one other device. Examples of communicationnetworks include local area networks (LANs), a wide area networks(WANs), the Internet, telephone lines, cable lines, radio channels,optical communications lines, and/or satellite communications links.Examples of communications protocols include Ethernet, Token Ring,Bluetooth™, and/or TCP/IP. Communication may be encrypted to ensureprivacy and prevent fraud. In addition to those described above,examples of devices that a gaming device 1300 may communicate withinclude a casino server, an authentication server, and other gamingdevices.

Turning to FIG. 17A, an embodiment of a system 1700A in which gamingdevices 1300 communicate with a casino server 1702 and an authenticationserver 1704, is depicted. According to this embodiment, a gaming device1300 may communicate with a casino server 1702 to perform traditionaloperations like enabling game play and providing comp points. Inaddition, a gaming device 1300 may also communicate with anauthentication server 1704 to authenticate data relating to usage of thegaming device 1300. The authentication server 1704 may in turncommunicate with one or more interested parties and/or their servers1706, 1708, 1710, 1712, 1714.

Turning to FIG. 17B, an embodiment of an alternative system 1700B inwhich gaming devices 1300 communicate with a casino server 1702 and thecasino server 1702 in turn communicates with an authentication server1704, is depicted. In certain circumstances, this embodiment may bepreferred, possibly for security reasons. For example, a casino server1702 may be located at a casino, and communicate with gaming devices1300 using a secure, private network. An authentication server 1704 maycommunicate with the casino server 1702 using a public network (e.g. theInternet) and only establish virtual connections (dotted line) to thegaming devices 1300. Having the authentication server 1704 communicatethrough the casino server 1702 instead of directly with the gamingdevices 1300 may help to minimize the risk that a maliciousattacker/hacker on the public network gains access to the gaming devices1300 by allowing the casino server 1702 to function as a gateway orfirewall.

According to some embodiments, a casino server 1702 may be insecure(e.g., a casino employee may be an attacker). In such an embodiment, itwould be very easy for an attacker (e.g., a casino employee) to performvarious man-in-the-middle attacks on communication between a gamingdevice 1300 and an authentication server 1704. One way to prevent theseattacks from being successful is to use an authentication code tocommunicate information about usage data, as described below.

Turning to FIG. 17C, an embodiment of an alternative system 1700C inwhich gaming devices 1300 communicate with only a casino server 1702, isdepicted. In such embodiments, authentication codes may be output to thecasino server, or using other methods as described below. Likewise, FIG.17D depicts an alternate embodiment of a system 1700D in which gamingdevices 1300 communicate with only an authentication server 1704. Forexample, a gaming device 1300 may operate independently, without anyneed for a network connection to a casino server.

In some embodiments, a casino server 1702 and an authentication server1704 may be operated by different entities or by the same entity. Forexample, a casino server 1702 may be operated by a casino where a gamingdevice 1300 is located, whereas an authentication server 1704 may beoperated by a trusted third party (e.g., an authentication serviceprovider). In some embodiments, a casino server 1702 and/or anauthentication server 1704 may be remote from a gaming device 1300. Insome embodiments, a gaming device 1300 may communicate with multiplecasino servers and/or multiple authentication servers. In someembodiments, different gaming devices 1300 may communicate withdifferent casino servers and/or different authentication servers. Notethat, according to some embodiments, a gaming device 1300 does notcommunicate using a communication network. For example, a gaming device1300 may output an authentication code to an operator using an outputdevice 1324 (e.g., an LCD display).

Thus, according to some embodiments, the system of the present inventionmay include an authentication server 1704, which may perform functionsrelating to decrypting or verifying authentication codes. FIG. 18depicts an example embodiment of an authentication server 1704. Thisexample embodiment includes a processor 1802, an input device 1812, anoutput device 1816, a communication port 1814, and a data storage device1804. In some embodiments, the components of the authentication server1704 may include those of the other devices, computers, and servers asdescribed above. In some embodiments, an authentication server 1704 maybe part of a casino server or other device. In some embodiments, anauthentication server 1704 may exist entirely as software. According tosome embodiments, the data storage device 1804 may store a program 1806,a gaming device database 1808, and a code verification database 1810.

Turning to FIG. 19, an example embodiment of a gaming device database1808 is depicted. According to some embodiments, a gaming devicedatabase 1808 may store information about gaming devices 1300 thatgenerate authentication codes. For example, this example embodimentstores a gaming device identifier 1900 that uniquely identifies a gamingdevice 1300, a gaming device location 1902 (e.g., what casino or otherparty currently owns or leases the gaming device 1300); a decryption key1904; and the gaming device year-to-date coin-in 1906 (an example ofusage data).

According to some embodiments, an authentication server 1704 may use adecryption key to determine usage data based on an authentication code.Alternatively, or in addition, an authentication server 1704 may receivean indication of usage data in an unencrypted format and verify thisusage data using an authentication code. According to some embodiments,an authentication server 1704 may store at least one decryption key 1904for at least one gaming device. This decryption key 1904 may be used fora variety of purposes relating to encryption, including decrypting atleast one authentication code, verifying at least one authenticationcode, decrypting usage data, verifying usage data, decrypting messagesfrom a gaming device 1300, and/or encrypting messages to send to agaming device. Various methods of verifying usage data using adecryption key are described in detail below along with the use of awide variety of alternative encoding/decoding methods.

According to some embodiments, a decryption key 1904 stored by anauthentication server 1704 may be based on a secret key 1316 stored by agaming device 1300. For example, different types of decryption keys 1904may be appropriate for different methods of generating an authenticationcode. Examples of decryption keys include a secret key (e.g., in asymmetric-key encryption system), a public key (e.g., in a public-keyencryption system), and a one-time-pad (e.g., corresponding to aone-time pad stored in a gaming device).

FIG. 20 depicts an example embodiment of a code verification database1810. According to some embodiments, a code verification database 1810may store information relating to verifying at least one authenticationcode. For example, the depicted embodiment stores an authentication code2000; a time received 2002; an indication of the gaming device thatgenerated the authentication code 2004; and an indication of whether theusage data has been verified 2006. Each authentication code 2000, forexample, that an authentication server 1704 receives may be stored in acode verification database 1810. According to some embodiments, anauthentication server 1704 may store an indication of when 2002 anauthentication code is received. According to some embodiments, anauthentication server 1704 may store an indication 2004 of what gamingdevice 1300 generated an authentication code 2000 (e.g., based oninformation that is provided along with the authentication code 2000).According to some embodiments, an authentication server 1704 may use anauthentication code 2000 to verify usage data for a gaming device andstore an indication of whether this usage data was verified 2006.Details regarding how usage data is verified using an authenticationcode are provided below.

Note that any of number of various devices may function as anauthentication server, including a computer server (note that a computerserver may be operated by a variety of different parties, as describedbelow); a casino server; and/or a gaming device 1300 (e.g. a gamingdevice 1300 may verify its own authentication code 2000, or anauthentication code 2000 generated by another gaming device, suchembodiments like these may be known as “self-authentication” or“mutual-authentication” or “self-verification” or “mutualverification”).

According to some embodiments, an operator of an authentication servermay use a terminal device (not shown) to communicate with theauthentication server 1704. Examples of terminal devices include apersonal computer, a network terminal, a laptop computer, a personaldigital assistant (PDA), a cellular telephone, a kiosk. For example, anoperator may use a PDA with a wireless Internet connection to provideinputs to an authentication server and receive outputs from theauthentication server. A mobile terminal device may be particularlyuseful for verifying authentication codes on the floor of a casino whilestill maintaining an authentication server in a secure location.

According to some embodiments, an authentication server may be operatedby an interested party. For example, a government regulatory group mayoperate an authentication server that verifies revenue informationrelating to a gaming device. This revenue information may then be usedto determine taxes owed by a casino that owns or leases the gamingdevice. In another example, a gaming device manufacturer may operate anauthentication server to verify that a casino is not unintentionallymisrepresenting usage data for a gaming device. For example, a gamingdevice manufacturer may have a licensing agreement with a casino inwhich the casino agrees to pay the gaming device manufacturer apercentage of revenues from a gaming device. In another example, agaming device feature licensor may operate an authentication server toverify that a casino or gaming device manufacturer is notmisrepresenting usage data for a licensed feature on a gaming device.For example, a gaming device feature licensor may have a licensingagreement with a casino or gaming device manufacturer in which thecasino or gaming device manufacturer agrees to pay the feature licensora fee based upon incremental increases of revenues related to use of thelicensed feature operating on a gaming device. In another example, acasino may operate an authentication server to verify usage datarelating to a portable gaming device that is operated by players. Forexample, the casino can verify that the version of the softwareoperating on the portable gaming device has not been altered orotherwise tamped with.

Turning to FIGS. 21 to 23, according to some embodiments, the presentinvention may include one or more of the following example processes:reporting usage data using an authentication code 2100; reporting usagedata using encoding of the data (i.e., without an authentication code)2200; and authenticating usage data 2300. Reporting usage data using anauthentication code 2100 may include tracking usage data 2102,determining an authentication code 2104, and outputting anauthentication code 2106. Reporting usage data using encoding of thedata 2200 may include accumulating usage data 2202, deriving encodeddata from the accumulated usage data 2204, and outputting the encodeddata to an operator 2206. Authenticating usage data 2300 may includereceiving usage data 2302, receiving an authentication code 2304, andverifying that the usage data corresponds to the authentication code2306.

According to some embodiments, a gaming device may track or record dataabout usage of the gaming device (also known as “usage data”). Asindicated above, a variety of different types of information may berecorded by a gaming device. According to some embodiments, a gamingdevice may track events that occur at the gaming device and informationabout these events. Examples of events include:

-   -   (i) outcomes that are generated by the gaming device    -   (ii) intra-game events (e.g., a player is dealt a card in video        poker, a player discards a card in video poker, a player gains        access to a bonus round on a slot machine)    -   (iii) payouts that are provided by the gaming device (e.g. 10        coin payout, a $100 jackpot)    -   (iv) money is inserted into the gaming device by a player (e.g.        using a bill acceptor or a coin slot)    -   (v) money is removed from the gaming device by a player (e.g., a        player presses the ‘cash out’ button)    -   (vi) a bonus is provided to a player (e.g., a player may earn a        10 coin bonus for inserting a $20 bill into a gaming device)    -   (vii) a feature is activated (e.g., a player activated Auto-Play        Mode on a gaming device)    -   (viii) a feature is deactivated (e.g., a player deactivates a        Betting the Don't Mode on a gaming device)    -   (ix) a feature affects operation of the gaming device (e.g., a        player wins a jackpot when a Double Jackpots mode is enabled on        a gaming device)    -   (x) a player identifies himself (e.g., a player may insert a        player tracking card into the gaming device)    -   (xi) a player operates an input device on the gaming device        (e.g., a player presses the ‘spin’ button on a slot machine, a        player uses a touch screen to select a card on a video poker        machine)    -   (xii) information may be output to a player using an output        device (e.g., an message may be displayed to a player on a video        screen alerting him that he only has 10 coins left)    -   (xiii) a casino employee opens the gaming device (e.g., to add        coins to the hopper)    -   (xiv) a casino employee closes the gaming device (e.g., after        adding coins to the hopper)    -   (xv) indications from sensors (e.g. a gaming device may have a        weight sensor that determines when a player is standing in front        of the gaming device)    -   (xvi) a gaming device incurs a cost (e.g., a player orders a        drink using an electronic menu on the gaming device, a player        contacts customer service to learn how a gaming device works, a        player is given a free tour of a gaming device)    -   (xvii) an authentication code is output from the gaming device        (e.g. according to the methods described below)    -   (xviii) an activation code is indicated to the gaming device        (e.g. according to the methods described below)    -   (xix) software or hardware on the gaming device is modified        (e.g., a machine is upgraded to include a new bonus round)    -   (xx) an attacker (e.g. an untrustworthy casino, a player)        tampers with the gaming device    -   (xxi) a gaming device is moved to a new location (e.g., if a        gaming device is portable)        In addition to events themselves, a gaming device may track        information about events, including:    -   (i) what event occurred    -   (ii) when the event occurred (e.g. what date, what time of day,        ordering of events)    -   (iii) how often an event occurred (e.g., 14 times, an average of        32.6 times per hour)    -   (iv) how much money was added/removed/involved in the event        (e.g. How much money did a player insert into a gaming device?        What size payout was provided to a player?)    -   (v) results of the event (e.g., What was a player's credit        balance after he won ajackpot? What is the state of a program on        a gaming device after the gaming device's software is upgraded?)    -   (vi) what player was operating a gaming device when an event        occurred    -   (vii) what caused an event to occur (e.g., why did a player win        a jackpot of 100 coins?)    -   (viii) other information describing the event (e.g., what        authentication code was provided, what activation code was        provided)    -   (ix) conditions under which an event occurred (e.g., what        percentage of gaming devices were in operation when an event        occurs)    -   (x) where an event occurred (e.g. if a gaming device is        portable) For example, a gaming device may include a position        sensor that determines where the gaming device is located when a        game is played.

According to some embodiments, a gaming device 1300 may storeinformation about events in an event database 1308. One example of anevent database is shown in FIG. 14.

Alternatively, or in addition, a gaming device 1300 may track statisticsrelating to usage of the gaming device 1300. Examples of statisticsinclude totals, averages, percentages and ratios, revenues (i.e.,“win”), theoretical win, number of prizes won, number of offerspresented or accepted, and play patterns (events, times, order, speed ofplay, strategies used by players). Totals, averages, percentages andother statistics may be calculated over a variety of different datasets, including:

-   -   (i) a set of sessions (e.g., all sessions longer than 10        minutes, all sessions since an authentication code was output)    -   (ii) a set of players (e.g., players staying at a casino hotel,        female players, players who are senior citizens, players who        have accepted offers in the past)    -   (iii) a period of time (e.g., the last 1 year, the last 1 month,        between 12 noon and 4 pm on Apr. 15, 2002)    -   (iv) a set bounded by at least one event (e.g., since an        authentication code was output, since an activation code was        received, since a jackpot or other outcome)    -   (v) a set of events at a location (e.g., games played Las Vegas        downtown, games played in Reno).

Examples of Totals Include:

-   -   (i) total revenues (e.g., the total revenues during a period of        time, the total revenues while a portable gaming device was at a        certain location)    -   (ii) a total number of occurrences of an event (e.g., a total        number of offers accepted by players, a total number of times        that a feature is activated)    -   (iii) a total value of a plurality of events (e.g., a total        amount of money cashed out of a gaming device, a total amount of        payouts provided)    -   (iv) a total amount of time (e.g., how many hours a gaming        device is operated, how many minutes a feature is used)

Examples of Averages Include:

-   -   (i) average session duration    -   (ii) an average number of occurrences of an event (e.g., an        average number of offers accepted by players)    -   (iii) an average value of a plurality of events (e.g., an        average credit balance, an average price of hotel rooms sold to        players through a gaming device)        Note that averages may be calculated on a ‘per unit’ basis. For        example, a gaming device may calculate an average coin-in per        game (e.g., 2.3 coins per game) or an average coin-in per        session (e.g., 165.2 coins per session). Examples of units for        averages include:    -   (i) per session    -   (ii) per game    -   (iii) per player    -   (iv) per hour (or other unit of time—seconds, minutes, days,        etc.)    -   (v) per event (e.g., per usage of a feature)

Examples of Percentages and Ratios Include:

-   -   (i) a percentage of players (e.g. what percentage of players use        a feature)    -   (ii) a percentage of sessions (e.g., what percentage of sessions        are longer than 3 hours)    -   (iii) a percentage of games (e.g., what percentage of games are        played with a particular feature enabled)    -   (iv) a percentage of events (e.g., what percentage of offers        presented to players are accepted)    -   (v) a percentage of time (e.g., what percentage of time a gaming        device is in use)        According to some embodiments, a gaming device may store        information about events in a game data database 1310. One        example of a game data database 1310 is shown in FIG. 15. Note        that information stored in the game data database 1310 may be        redundant with information stored in an events database. It is        possible that a gaming device may store either database, or both        databases. In the examples provided herein, both databases are        included to demonstrate that usage data may be accumulated in a        variety of different forms.

According to some embodiments a gaming device may store relativeperformance data. In other words, data that indicates the performance ofthe gaming device compared to: (i) a baseline measure and/or (ii) anaverage performance level of similar machines, may be stored.

According to some embodiments, a gaming device may determine and/ortrack one or more payments to be provided based on usage of a gamingdevice. For example a gaming device may determine a payment that shouldbe provided to an interested party such as a regulatory group, licensor,or game manufacturer. In another example, a gaming device may determinea payment to be provided by an interested party such as a subsidizer.

Note that information about the location of a gaming device (e.g. asdetermined by a position sensor) may be a type of usage data.Information about the position of a gaming device may be particularlyuseful for ensuring that a gaming device complies with local laws.Examples include:

-   -   (i) Certain games may be illegal in certain locations. For        example, it may be illegal to play games of chance in        Massachusetts.    -   (ii) Certain locations may levy taxes on games. For example, the        state of Nevada may require that a proprietor of a gaming device        (e.g. a casino) pay a tax on all profits obtained from a gaming        device.    -   (iii) In some locations, games may be only be legal for certain        players. For example, it may be illegal for players under the        age of 19 to play games of skill for cash prizes in Nebraska and        Alabama.    -   (iv) In some locations, there may be limits on the value of a        prize that may be provided to a player. For example, Arizona        limits the amount of prize money that players can win by playing        games.        Note that various interested parties may be interested in the        location of a gaming device, including:    -   (i) regulatory groups (e.g., state government)—For example, law        enforcement may be interested in ensuring that players do not        play games in locations where it is illegal. In a second        example, tax collectors may be interested in collecting taxes        based on games played in their jurisdiction.    -   (ii) casinos—For example, a casino may be interested in ensuring        that players do not break the law and in determining appropriate        taxes and licensing fees to pay based on the location of a        gaming device.    -   (iii) game manufacturers—For example, a game manufacturer may        lease a gaming device to a casino for a percentage of revenues        generated by the gaming device. The game manufacturer may be        interested in verifying the revenues generated by the gaming        device to ensure that the casino provides the correct lease        payments.    -   Information about the location of a gaming device may be tracked        in various ways, including:    -   (i) the general location of a gaming device (e.g. the state of        California)    -   (ii) a precise location (e.g. a latitude and longitude)    -   (iii) borders crossed by the gaming device (e.g., a gaming        device moved outside of a casino and onto the street in Las        Vegas)        According to some embodiments, game play on a gaming device may        be enabled or disabled based on the location of the gaming        device. For example, if a player takes a portable gaming device        into an area where games of chance are illegal, then games of        chance may be disabled on the gaming device. In a second        example, a gaming device may disable games of skill if a player        is under the age of 19 and the gaming device is currently        located in Nebraska. Information about the enabling and        disabling of game play on a gaming device may be tracked as        usage data.

In the embodiments described above, information about usage of a gamingdevice is tracked by the gaming device. Alternatively, or in addition,information about usage of a gaming device may be tracked using a server(e.g., a casino server 1702 or an authentication server 1704). Forexample, a gaming device 1300 may transmit usage information to a casinoserver 1702 and the casino server 1702 may store this information in anevent database 1308 and a game data database 1310. If a server is usedto track data, then the gaming device, communications link, and servershould all be secure to avoid tampering with the data (e.g., by a casinoemployee). For example, a casino employee may intercept or modifycommunications between a gaming device and the server, thereby alteringthe data. It may be difficult or costly to ensure that the casinoemployees cannot tamper with data transmitted from a gaming device to aserver or stored on a hard drive on the server.

Using a server to track data from a plurality of gaming devices may bemore cost effective or convenient than tracking data individually oneach of the gaming devices. For example, it may be costly to include asecure memory and authentication code generation capabilities in eachgaming device.

According to some embodiments, a gaming device may generate anauthentication code based on data described above. According to variousembodiments of the invention, an authentication code may, for example,include:

-   -   (i) a digital signature    -   (ii) a message digest    -   (iii) a fingerprint    -   (iv) a cryptographic checksum    -   (v) a cryptographic hash    -   (vi) a data integrity check (DIC)    -   (vii) a manipulation detection code (MDC)    -   (viii) a message authentication code (MAC)    -   (ix) a data authentication code (DAC)        Many other embodiments of authentications codes are also        possible.

According to some embodiments, determining an authentication code mayinclude hashing or compressing usage data. Various types of hashfunctions or compression functions maybe used in accordance with thepresent invention. Alternatively, determining an authentication code maynot include any hashing or compression. For example, an authenticationcode could be determined by just encrypting a set of usage data asdescribed below. According to some embodiments, determining anauthentication code may include using a one-way function. According tosome embodiments, a function H may be considered to be a one-wayfunction if h=H(M), where h is known as a “hash value” and M is amessage; given M, it is easy to compute h; given h, it is hard tocompute M such that H(M)=h; and given M, it is hard to find anothermessage M′ such that H(M)=H(M′).

Advantages and disadvantages of one-way functions and other functionsdescribed below are known to those skilled in the art. For furtherdetails, one of ordinary skill in the art may refer to a book by BruceSchneier, entitled APPLIED CRYPTOGRAPHY, PROTOCOLS, ALGORITHMS, ANDSOURCE CODE IN C, (2d Ed, John Wiley & Sons, Inc., 1996), which isincorporated herein by reference in its entirety. For example, oneadvantage of using a one-way function to determine an authenticationcode is that it prevents a casino from reading an authentication code,generating counterfeit usage data based on the authentication code, andthen claiming that authentication code corresponds to the counterfeitusage data. If a one-way function is used to generate an authenticationcode, it should be very difficult for a casino to generate counterfeitusage data based on the authentication code.

According to some embodiments, determining an authentication code mayinclude using a one-way compression function. A one-way compressionfunction may be a one-way function with an additional restriction thatthe length of h is less than the length of M.

According to some embodiments, determining an authentication code mayinclude using a one-way hash function. A one-way hash function may be aone-way function with an additional restriction that the length of h isconstant.

Examples of One-Way Hash Functions Include:

-   -   (i) Snefru by Ralph Merkle    -   (ii) N-Hash by Nippon Telephone and Telegraph    -   (iii) MD4 (Message Digest 4) by Ron Rivest    -   (iv) MD5 (Message Digest 5) by Ron Rivest    -   (v) MD2 (Message Digest 2) by Ron Rivest    -   (vi) SHA (Secure Hash Algorithm) by the NIST and the NSA    -   (vii) RIPE-MD by the RIPE Project    -   (viii) HAVAL        Similarly, determining an authentication code may include        determining one or more of the following:    -   (i) contraction function    -   (ii) message digest    -   (iii) fingerprint    -   (iv) cryptographic checksum    -   (v) cryptographic hash    -   (vi) data integrity check (DIC)    -   (vii) manipulation detection code (MDC)    -   (viii) message authentication code (MAC)    -   (ix) data authentication code (DAC)    -   (x) digital signature        It may be noted from the above examples that an authentication        code may be encrypted.

According to some embodiments, a function used in determining anauthentication code may be collision resistant. A function H may becollision-resistant if it is hard to find two random messages M and M′,such that H(M)=H(M′).

According to some embodiments, any compression function (i.e., a one-wayor two-way compression function) may be used to compress usage data intoan authentication code. Using a compression function may be helpful inreducing the size of an authentication code (e.g., to reduce bandwidthcosts or to make it easier for a person to remember or communicate).Note that a compression function may be “lossy” (i.e., some usage datathat is compressed may not be recoverable) or “loss-less” (i.e., allusage data that is compressed is recoverable). Similarly, determining anauthentication code may include a step of evaluating a two-way hashfunction.

As noted above, determining an authentication code may or may notinclude determining a result of a hash function/compression function. Ineither case, determining an authentication code may include determininga result of an encryption function or cryptographic protocol. Forexample, a gaming device may determine an authentication code by hashingor compressing a set of usage data to produce a hash value (as describedabove) and encrypting the hash value to produce the authentication code.Alternatively, these steps could be performed in reverse order (i.e.,the usage data could be encrypted and then hashed to produce anauthentication code). In another example, a gaming device may determinean authentication code by encrypting a set of usage data to produce theauthentication code. In another example, a gaming device may determinean authentication code using a one-way hash function with a key (alsoknown as a message authentication code). Methods of encryption are knownto those skilled in the art, and are not described in detail herein.

According to some embodiments, an authentication code may be generatedusing a public-key encryption algorithm. For example, a gaming devicemay store a private key that it keeps secret and publish a public key.The gaming device may then encrypt usage data using the private key toproduce an authentication code. It may then transmit this authenticationcode to an authentication server. The authentication server may then usethe public key to decrypt the authentication code and verify the usagedata. Examples of public-key encryption algorithms include:

-   -   (i) RSA    -   (ii) Pohlig-Hellman    -   (iii) Diffie-Hellman    -   (iv) ElGamal    -   (v) Rabin    -   (vi) McEliece    -   (vii) elliptic curve cryptosystems    -   (viii) LUC    -   (ix) finite automaton public-key cryptosystems        Note that public-key encryption is generally much more        computation-intensive than symmetric key encryption. Therefore        symmetric key encryption may be preferred for use in generating        an authentication code.

According to some embodiments, an authentication code may be generatedusing a symmetric encryption algorithm. For example, a gaming device mayuse a secret key to encrypt usage data and generate an authenticationcode. It may then transmit this authentication code to an authenticationserver. The authentication server may then use the same secret key todecrypt the authentication code and verify the usage data.

According to some embodiments, an authentication code may be generatedusing a block cipher. Examples of block ciphers include:

-   -   (i) DES    -   (ii) Triple DES    -   (iii) IDEA    -   (iv) Blowfish    -   (v) Luficer    -   (vi) Madryga    -   (vii) NewDES    -   (viii) FEAL    -   (ix) REDOC, REDOC II, REDOC III    -   (x) LOKI, LOKI91    -   (xi) Khufu and Khafre    -   (xii) RC2    -   (xiii) MMB    -   (xiv) CA-1.1    -   (xv) Skipjack    -   (xvi) GOST    -   (xvii) CAST    -   (xviii) SAFER K-64    -   (xix) 3-Way    -   (xx) Crab    -   (xxi) SXAL8/MBAL    -   (xxii) Pohlig-Hellman

According to some embodiments, an authentication code may be generatedusing a stream cipher. Examples of stream ciphers include:

-   -   (i) LFSR    -   (ii) FCSR    -   (iii) A5    -   (iv) Hughes XPD/KPD    -   (v) Nanoteq    -   (vi) Rambutan    -   (vii) Additive generators    -   (viii) Gifford    -   (ix) Algorithm M    -   (x) RC4    -   (xi) SEAL    -   (xii) WAKE    -   (xiii) Non-Linear Feedback Shift Registers    -   (xiv) Pless Generator    -   (xv) Cellular Automation Generator    -   (xvi) 1/p Generator    -   (xvii) crypt(1)    -   (xviii) Rip van Winkle Cipher    -   (xix) Diffie's Randomized Stream Cipher    -   (xx) Maurer's Randomized Stream Cipher

According to some embodiments, a single function may perform bothhashing and encryption. For example, an authentication code may be a“message authentication code” or MAC. According to some embodiments, aMAC may be generated using a one-way hash function that requires the useof both an input string and a specific key string. (The “key” is anadditional input string, which may be secret.) Only someone with the keycan calculate the hash value (e.g., because the hash value is encryptedwith the key). Some examples of MACs include:

-   -   (i) CBC-MAC    -   (ii) Message Authenticator Algorithm (MAA)    -   (iii) Bidirectional MAC    -   (iv) Jueneman's Methods    -   (v) RIPE-MAC    -   (vi) IBC-Hash    -   (vii) A one-way hash function may be used as a MAC by        concatenating a key with a message and then hashing the        concatenation.    -   (viii) Stream Cipher MAC

It is also possible to use a symmetric or public key block encryptionalgorithm to produce a MAC. Examples include:

-   -   (i) Modified Davies Meyer    -   (ii) Preneel-Bosselaers-Govaerts-Vandewalle    -   (iii) Quisquater-Girault    -   (iv) LOKI Double-Block    -   (v) Parallel Davies-Meyer    -   (vi) Tandem and Abreast Davies-Meyer    -   (vii) MDC-2 and MDC-4    -   (viii) AR Hash Function    -   (ix) GOST Hash Function    -   (x) DSA (Digital Signature Algorithm)    -   (xi) Ong-Schnorr-Shamir    -   (xii) ESIGN

According to some embodiments, an authentication code may be generatedusing a one-time pad. For example, when a gaming device is manufactured,a one-time pad may be generated and stored in a ROM on the gamingdevice. A duplicate copy of this one-time pad may be stored on anauthentication server. Each time an authentication code is generated, anunused portion of the one-time pad may be used to encrypt theauthentication code. When the one-time pad runs out, a gaming devicemanufacturer or other party may supply a new one-time pad (e.g., bymanually installing a new ROM in the gaming device). Note that using aone-time pad may be well-suited to encryption for gaming devices, sincea gaming device manufacturer can easily generate a large one-time padand securely implant in a gaming device when the gaming device is beingmanufactured. Depending on how this one-time pad is used, the pad maylast for the entire lifetime of the gaming device. For example, anaverage gaming device only stays on the floor of a casino for two tofour years before being replaced, and it would be feasible for a gamingdevice to generate an authentication code of size 5 kb on a monthlybasis. In such an example a gaming device would only need to store aone-time pad that was at least 240 kb.

Note that generating an authentication code may or may not include usinga secret key. If a secret key is used to generate an authenticationcode, this secret key may be stored by the gaming device, as describedabove. Note that a variety of different types of secret keys arepossible, including symmetric encryption keys, private keys forpublic-key encryption, and one-time pads.

In some embodiments, an authentication code may be generated using asecret algorithm. This algorithm may not be readily ascertainable orknown by an attacker (e.g. a casino employee).

According to some embodiments, an authentication code may be encoded.Note that encrypting is only one method of encoding a message. Forexample, an authentication code may be encoded using one or more of thefollowing:

-   -   (i) a substitution cipher—For example, the number 5 may be        substituted for the number 1, the number 8 substituted for the        number 9, meaning that the plaintext “19” would be encoded as        “58.”    -   (ii) a transposition cipher—For example, the digits of a number        may be rotated 3 digits to the left, so that the number “12345”        becomes “45123.”    -   (iii) a code—For example, the word “Hamlet” might be the        authentication code for the message “13,567 coins have been        played on this gaming device during the last week.”

According to some embodiments, an authentication code may be enciphered.

According to some embodiments, an authentication code may be generatedusing steganography. For example, authentication code may be hidden in alarge file of usage data for a gaming device, making it more difficultfor an attacker to identify the authentication code.

The following examples of encryption are provided to give an overview afew different ways that an authentication code may be encrypted andcommunicated to an authentication server. Many other methods are alsopossible, as indicated above.

Example # 1 Message Authentication Code

Assume a gaming device and an authentication server share a secret key.

-   -   1. The gaming device hashes usage data with a MAC and the shared        secret key to form an authentication code.    -   2. The authentication code and the usage data are communicated        to the authentication server.    -   3. The authentication server reads the authentication code and        hashes the usage data with the shared secret key.    -   4. If the generated hash matches the received hash, the        authentication server accepts the usage data as authentic.

Example #2 Encryption with Public Key Cryptography

Assume a gaming device has a public-key/private key pair and anauthentication server knows the gaming device's public key.

-   -   1. The gaming device encrypts usage data with the private key to        form an authentication code.    -   2. The authentication code is communicated to authentication        server.    -   3. The authentication server decrypts the authentication code        with the public key of the gaming device.    -   4. If the message is intelligible, the authentication server        accepts the authentication code as authentic.        A sample algorithm for this procedure is RSA.

Example #3 Signing with Public Key Cryptography

Assume a gaming device has a public-key/private key pair and anauthentication server knows the gaming device's public key.

-   -   1. The gaming device signs the usage data with the private key        to form an authentication code (e.g., a digital signature)    -   2. The authentication code and the usage data are communicated        to the authentication server.    -   3. The authentication server verifies the authentication code        using the usage data and the public key. The mathematics of        verification indicates whether the usage data and authentication        code are authentic.

Example #4 Symmetric Encryption

Assume a gaming device and an authentication server share a secret key.

-   -   1. The gaming device encrypts usage data with the shared secret        key to form an authentication code.    -   2. The authentication code is communicated to the authentication        server.    -   3. The authentication server reads and decrypts the        authentication code with the same key.    -   4. If the message is intelligible, then the authentication        server accepts the authentication code as authentic.

As indicated above, the present invention may provide a variety ofdifferent benefits (e.g. data legitimacy, data paternity, dataintegrity, gaming device integrity, transmission integrity,non-repudiation). Some of these benefits may be enabled by includingspecific information in an authentication code. For example, including agaming device identifier in an authentication code may help to ensurethat data paternity is verifiable. Thus, a few different types of datathat are particularly useful to include in an authentication code aredescribed below.

Note that “including data” in an authentication code may comprisehashing/compressing the data, encrypting the data, or otherwiseproviding an indication of the data using an authentication code. Notethat it is preferred that data included in an authentication code beencrypted, thereby preventing an attacker (e.g., a casino employee) fromaltering the authentication code and spoiling one or more of thebenefits of the invention. For example, an authentication code mayinclude an indication of one or more of the following:

-   -   (i) time—Including when an authentication code is generated or        when an event occurs may prevent an attacker (e.g., a casino        employee) from reusing old authentication codes. For example, if        an authentication code did not include an encrypted time, then a        casino that communicates authentication codes to an        authentication server on a monthly basis might use the same        authentication code(s) each month, thereby claiming the same        usage data, even if this was actually not the case. Note that a        time that is included in an authentication code may be generated        by a clock that is protected by a secure perimeter on a gaming        device.    -   (ii) gaming device identifier—Including information identifying        a gaming device may help to prevent an attacker (e.g., a casino        employee) from using the same authentication code for multiple        machines. For example, each gaming device may have a different        secret key. Therefore two gaming devices would produce different        authentication codes even if their usage data was identical. In        a second example, a plurality of gaming devices at a casino may        have the same secret key, but authentication codes generated by        each gaming device may include information identifying the        gaming device (e.g., a gaming device identifier). If an        authentication code does not include encrypted information that        differentiates between gaming devices, then a casino might use        the same authentication code for two or more different gaming        devices, and claim that these two or more gaming devices both        had the same usage data, even if this was actually not the case.    -   (iii) previous authentication code—Including information about a        previous authentication code generated by a gaming device may        make it more difficult for a attacker to counterfeit        authentication codes. For example, an authentication code for        October may be dependent on an authentication code for        September. This practice may be known as “chaining”, since a        chain of linked authenticated codes may be formed.    -   (iv) at least one indication by an authentication        server—According to some embodiments, generating an        authentication code may include using a challenge-response        protocol. For example, an authentication server may generate a        random number or sequence number (also referred to as a        “nonce”), encrypt this random number using a secret key that it        shares with a gaming device (or an appropriate public        key/private key pair), and communicate the encrypted random        number to the gaming device. The gaming device may then decrypt        the encrypted random number and include the random number in an        authentication code that is subsequently generated. Note that        since an attacker would not be able to decrypt the encrypted        random number, the attacker would be unable to include the        random number when generating an authentication code.    -   (v) a sequence number—For example, a sequence number included in        an authentication code may be incremented by one every time a        gaming device generates an authentication code. An        authentication server may store the most recent sequence number        in memory and only accept an authentication code if the sequence        number included in the authentication code is one greater than        the most stored sequence number.    -   (vi) a random number—For example, a gaming device may generate a        random number and include this random number in an        authentication code that is in turn communicated to an        authentication sever. The authentication server may maintain a        database of all random numbers received from the gaming device.        If the authentication server receives an authentication code        that includes a random number that is already in the database,        then there is a good chance that this authentication code is a        duplicate. If the authentication server receives an        authentication code that includes a random number that is not in        the database, then the authentication code may be accepted as        fresh.    -   (vii) modifications to hardware or software of a gaming        device—Including information about the current or past state of        the hardware or software of a gaming device may help to prevent        an attacker from modifying a gaming device to produce different        usage data or different authentication codes. For example, a        gaming device may compute a hash value, MAC, or digital        signature of its own program using methods similar to those        described above. An authentication server may then use this        information to determine whether software on a gaming device has        been modified (e.g., by comparing a generated hash value to a        known hash value for the gaming device's program). In a second        example, a gaming device may track the natural random variations        in the magnetic memory media of a data storage device or other        memory (see U.S. Pat. No. 5,235,166 to Fernandez for details,        the entirety of which is incorporated herein by reference). If        these variations change, then it could be a sign that        information on the magnetic memory media has been altered (e.g.        an attacker has altered the program of the gaming device). In a        third example, a hash value for a game program may be verified        as the game program is read into memory (e.g., random access        memory or RAM).    -   (viii) tampering with a gaming device—Including information        about tampering with a gaming device may help to alert an        authentication server or other party if a gaming device has been        modified, a secure perimeter has been breached, or a secret key        stored in the gaming device has been compromised. For example, a        gaming device may track whether a secure perimeter is intact. If        the secure perimeter is not intact, this may be a sign that the        gaming device is no longer secure and that usage data or        authentication codes generated by the gaming device could be        modified.

Note that some of the data described above may already be included in anauthentication code as usage data. Also note that a gaming device mayinclude non-usage data along with usage data when generating anauthentication code.

In addition to the detailed descriptions provided above, someembodiments relating to authentication codes are now described. Careshould be taken when selecting an encryption algorithm for use ingenerating an authentication code. Since a casino may operate a gamingdevice, it is likely that a casino may be able to determine some or allusage data relating to the gaming device. For example, current gamingdevices have meters that display some game related data, such ascoin-in. A casino may even be able to control how much a gaming deviceis used, thereby controlling what usage data is included in anauthentication code. Therefore, care should be taken to pick anencryption algorithm that is strong against a known-plaintext attack,chosen-plaintext attack, or an adaptive-chosen-plaintext attack.

Note that generating an authentication code may or may not include ahashing or compression step. However, it is preferred that generating anauthentication code include an encryption step, otherwise it may bepossible for a casino employee to alter some or all of an authenticationcode or usage data associated with a gaming device.

According to some embodiments, an authentication code for a gamingdevice may be determined by the gaming device. Alternatively, anauthentication code may be determined by a casino server or otherdevice. However, note that if a casino server or other device generatesan authentication code, then communication between the casino server andthe gaming device may need to be secure from attackers.

Once a gaming device or other device has determined an authenticationcode (e.g. as described above), this authentication code may be output.

An authentication code may be output in a variety of ways, including:

-   -   (i) over a network—For example, a gaming device may use a        communication network to communicate an authentication code to        an authentication server or a casino server.    -   (ii) using an output device (e.g., a display)—For example, a        game may display an authentication code to a casino employee        using a touch screen. In a second example, a gaming device may        display an authentication code to a casino employee using an LCD        display that is hidden from view of players who use the gaming        device (e.g., an LCD screen may be located behind a front panel        of a gaming device that a casino employee uses a key to open).    -   (iii) on a substrate (e.g., a piece of paper, a magnetic disk,        an optical disk)—A gaming device may use an output device (e.g.,        a printer, a disk drive, a compact disc (CD) burner) to write an        indication of an authentication code onto a substrate. For        example, a gaming device may use a dot matrix printer to print        an authentication code on a piece of cashless gaming receipt. In        a second example, a gaming device may use a thermal printer to        print a bar code (i.e., an indication of an authentication code)        on a piece of paper. In a third example, a gaming device may use        a disk drive to store an authentication code on a floppy disk.        Note that additional information besides an authentication code        may also be written on the substrate (e.g., usage data, an        address of a game manufacturer).    -   (iv) to a terminal device (e.g., a PDA, a laptop computer)—For        example, a gaming device may transmit an authentication code to        a PDA using an infra-red communications link. According to some        embodiments, the terminal device may verify the authentication        code by communicating it to an authentication server, as        described above.

An authentication code may be output to a variety of different parties,including:

-   -   (i) a casino employee—For example, on the first Tuesday of every        month at 4 am, a casino employee may open up the front panel of        a gaming device and read an authentication code from an LCD        display hidden inside the gaming device. In a second example, a        casino employee may press a button on a gaming device to prompt        the gaming device to print an authentication code on a receipt        for the gaming device. In a third example, a casino employee who        operates a casino server may view an authentication code using        an output device.    -   (ii) a regulatory group—For example, a gaming device may print a        “receipt” that includes usage data and an authentication code.        When filing its tax return, a casino may include this receipt. A        regulatory group (e.g., a state tax agency) may then use an        authentication server to verify that the usage data matches the        authentication code, thereby verifying that the usage data has        not been altered in any way (e.g., where a route operator        defrauded a casino).    -   (iii) manufacturer employee—For example, an employee of a game        manufacturer may visit a casino once a year to verify        authentication codes on the casino's gaming devices. The        employee may visit each gaming device and use a wireless        handheld device (e.g., a PDA) to download an authentication code        from the gaming device. This authentication code may then be        used to verify usage data relating to the gaming device (e.g.        usage data upon which lease payments are based).    -   (iv) player—For example, a gaming device may not have access to        a communication network. In such an embodiment, the invention        may be used to enable players of the gaming device to receive        comps and other bonuses based on their usage of the gaming        device. For example, when a player completes a gaming session at        a gaming device, the gaming device may print a receipt for this        gaming session, describing usage data (e.g., how long the player        operated the gaming device, his total coin-in). The player may        then bring this receipt to a cashier at the casino and be        awarded comp points or another benefit based on his usage of the        gaming device.

According to some embodiments, outputting an authentication code from agaming device may include receiving an indication from at least oneparty.

Examples Include:

-   -   (i) An authentication code may be encrypted using a        challenge-response protocol.    -   (ii) Output of an authentication code may be password-protected.        For example, a party (e.g., a casino employee, a manufacturer        employee) may be prompted to provide a password in order for an        authentication code to be output. In a second example, a party        may indicate a password using an input device (e.g., a keypad on        a gaming device, a computer keyboard on an authentication        server, a touch screen on a portable handheld device).    -   (iii) A gaming device may receive an indication of a password        using a communications network. For example, an authentication        server may transmit a password to a gaming device. Based on the        password, the gaming device may then transmit an authentication        code to the gaming device.

According to some embodiments, output of an authentication code may besecure. For example, a secure (e.g., encrypted) communications link maybe used to transmit an authentication code from a gaming device to anauthentication server. Alternatively, output of an authentication codemay not be secure. For example, a LCD panel on the back of a gamingdevice may display an authentication code.

According to some embodiments, a gaming device may output usage datainstead of or in addition to an authentication code.

Note that as used herein the phrase “verifying an authentication code”is synonymous with “verifying usage data using an authentication code.”According to some embodiments, an authentication server may receive anindication of an authentication code. For example, a gaming device,casino server, or other device may transmit an authentication code to anauthentication server using a communications network. In anotherexample, an operator of an authentication server (e.g., an employee ofan interested party) may use an input device (e.g., a computer keyboard)to enter an authentication code.

Note that an authentication code may be communicated to an operator ofan authentication server in a variety of different ways. Examplesinclude:

-   -   (i) A casino employee may telephone or email an operator of an        authentication server and tell him an authentication code that        was output by a gaming device. The operator may then use a        keyboard to input this authentication code into an        authentication server and verify that usage data for the gaming        device.    -   (ii) A gaming device may print out a receipt that includes an        authentication code. This receipt may be mailed to an operator        of an authentication server (e.g., as part of a tax return or        lease payment). The operator may then use an input device (e.g.,        a bar-code scanner) to input the authentication code into the        authentication server and verify usage data for the gaming        device.    -   (iii) A gaming device may use an output device (e.g., a video        display) to output an authentication code to an operator of an        authentication server. The operator may then use an input device        (e.g., a wireless handheld device) to indicate the        authentication code to the authentication server.    -   (iv) Note that an operator of an authentication server may be a        player or other party. For example, a gaming device may output a        cashless gaming receipt to a player that includes an        authentication code. The player may then visit a gaming device        manufacturer's website and enter the authentication code from        the cashless gaming receipt. Note that in this example, the        player is an operator of the gaming device manufacturer's        website, which may function as an authentication server.        According to some embodiments, a player may receive a benefit        based on providing an authentication code to a gaming device        manufacturer.

According to some embodiments, verifying an authentication code mayinclude decrypting the authentication code. Various methods ofdecrypting an authentication codes are possible; the appropriate methodfor decrypting an authentication code will depend on what method wasused to encrypt the authentication code. Note that authentication servermay store a decryption key (e.g., a key for a symmetric encryptionalgorithm or a public key for a public-key encryption algorithm) toenable it to decrypt an authentication code generated by a gamingdevice.

According to some embodiments, an authentication server may receive atleast one indication of usage data in addition to an authenticationcode. Examples include:

-   -   (i) Each month, a casino may report usage data and an        authentication code to an interested party (e.g. a regulatory        group, a game manufacturer). The usage data may be unencrypted        and the authentication code may be used to verify that the usage        data has not been altered in any way.    -   (ii) Each month, a casino may report usage data to an interested        party. At the end of a year, the casino may report an        authentication code to the interested party. The interested        party may then use this authentication code to verify the usage        data from the previous 12 months.

(iii) Once a week, a gaming device may transmit an authentication codeto an authentication server, so that by the end of a month, theauthentication server has received four authentication codes from thegaming device. At the end of the month, a casino may provide anindication of usage data for the gaming device. To verify the usagedata, the authentication server may compare the usage data to theinformation provided by the 4 authentication codes.

Alternatively, authentication codes may be the only indications of usagedata that an authentication server receives. For example, anauthentication code may be an encrypted version of usage data. Bydecrypting the authentication code, an authentication server may be ableto determine the usage data.

According to some embodiments, verifying information included in anauthentication code may include comparing the information to one or moreexpected values for the information. Examples of expected valuesinclude:

-   -   (i) usage data—As described above, an authentication server may        receive an indication of usage data in addition to an indication        of an authentication code. In such an embodiment, information in        the authentication code may be compared to the usage data. If        the two indications of the usage data do not match, then an        attacker may have altered the usage data. As described above, a        variety of different types of usage data are possible. According        to some embodiments, an authentication server may compare hash        values of usage data. For example, an authentication server may        compute a hash of a set of usage data and compare this hash to a        hash value indicated in an authentication code. Various methods        of hashing and compression are also described above.    -   (ii) time—For example, an authentication code may include an        indication of what time the authentication code was generated        (e.g., as described above). An authentication server may track        when the authentication code was received by the authentication        server. If these two times do not match (e.g., within a        prescribed window), then this may be a clue that an attacker is        attempting to reuse an authentication code or that delivery of        an authentication code was delayed for some reason. In a second        example, the authentication server may check to see that the        time on the authentication code matches the time on the usage        data. If these values do not match, then an attacker might be        trying to reuse old usage data.    -   (iii) gaming device identifier—The authentication server may        check to make sure that the usage data and the authentication        code both came from the same machine. If usage data and        authentication code came from different gaming devices, then an        attacker might be trying to reuse usage data from a first gaming        device as usage data for second gaming device.    -   (iv) sequence number—For example, an authentication server may        include a sequence number, previous authentication code, or        random number as described in above. If this sequence number,        previous authentication code, or random number does not match a        value that is expected by an authentication server (e.g., the        next number in a sequence, a previous authentication code, or a        stored random number), then this may indicate that the        authentication code is a forgery or that something else is        amiss.    -   (v) state of the gaming device—As descried in above, an        authentication code may include an indication of the state of        the hardware or software of a gaming device. If this indication        of the state of the gaming device does not match an expected        value for the state of the gaming device, then an authentication        code or usage data may not be accepted. For example, an        authentication code may include a hash of a gaming device's        program. To verify that the gaming device's program has not been        altered, an authentication server may compare this hash to a        stored hash value for the gaming device's program. If these two        hash value do not match, then the gaming device's program may        have been altered.

According to some embodiments, multiple authentication codes may be usedto verify one set of usage data. For example, a casino may report usagedata for a gaming device (e.g., revenues) to a regulatory group on anannual basis or have encoded usage data audited on a probabilistic basis(e.g. on a regular schedule or via random sampling). The gaming devicemay generate authentication codes on a monthly basis. An authenticationserver operated by the regulatory group may use the twelveauthentication codes for the year to verify the usage data for the year.Similarly, multiple authentication codes may be used to verify multiplesets of usage data. According to some embodiments, one authenticationcode may be used to verify multiple sets of usage data. For example, acasino may report usage data for a gaming device (e.g., revenues) to agame manufacturer on a monthly basis. At the end of a year, the gamingdevice may generate an authentication code for all usage data from theentire year. An authentication server operated by the game manufacturermay use the authentication code to verify the usage data for all twelvemonths of the year.

According to some embodiments, an authentication server may store agaming device database. An embodiment of a gaming device database 1808is shown in FIG. 19. According to some embodiments, an authenticationserver may store a code verification database. An embodiment of a codeverification database 1810 is shown in FIG. 20.

According to some embodiments, a gaming device may store usage data in asecure location and output the usage data in a secure manner. In such anembodiment, the gaming device may not generate or output anauthentication code. An attacker (e.g., a casino employee) may beprevented from altering the usage data because the usage data is storedand output securely. Thus, according to some embodiments, usage data maybe stored securely. For example, usage data may be stored in one or moredatabases (e.g., an event database 1308, a game data database 1310) thatare protected by a secure perimeter. In another example, usage data maybe encrypted when stored on a data storage device. For example, aprocessor in a gaming device may store a secret key 1316 that is used toencrypt information that is stored in a database. Since an attacker(e.g., a casino employee) does not know this secret key 1316, theattacker may be unable to alter the usage data stored in the database.

According to some embodiments, usage data may be output securely.

Examples Include

-   -   (i) A gaming device may transmit usage data securely over a        communication network. For example, communications between a        gaming device and an authentication server may be encrypted        using a secret key that is known only to the gaming device and        the authentication server. Since an attacker (e.g., a casino        employee) does no know this secret key, the attacker would not        be able to modify the usage data.    -   (ii) A gaming device may connect to a terminal device (e.g., a        PDA, a laptop computer) using a secure communication link. For        example, a manufacturer employee may connect a tablet computer        to a USB (universal serial bus) port on a gaming device. Usage        data may then be transferred from the gaming device to the        laptop computer using this USB link.    -   (iii) A gaming device may output usage data using a secure        output device (e.g., a video display, a disk drive). For        example, a secure perimeter may protect a gaming device and an        associated output device from tampering.    -   (iv) A gaming device may require an operator (e.g., a        manufacturer employee) to provide a password in order to access        data that is stored on a data storage device.

According to some embodiments, usage data may not be stored on a gamingdevice at all. Instead, usage data may be transmitted to an alternatedevice (e.g., a casino server, an authentication server) as is it isgenerated. This alternative device may then store the usage datasecurely and output it in an secure manner.

According to some embodiments, a single authentication code may begenerated for a plurality of gaming devices. For example, a casinoserver or other device may track usage data relating to a plurality ofgaming devices. The casino server may then generate an authenticationcode based on the usage data and communicate (e.g., transmit) theauthentication code to an authentication server for verification.

According to some embodiments, an authentication code may be generatedby a casino server as opposed to a gaming device. In such an embodiment,there is a need to prevent an attacker from modifying usage data duringat least the following processes:

-   -   (i) transmitting usage data from a gaming device to the casino        server    -   (ii) storing usage data on the casino server (e.g., in a data        storage device)    -   (iii) generating an authentication code based on usage data        According to some embodiments, at least a portion of a casino        server may be secure. A casino server may include a secure        perimeter similar to the one described above.

According to some embodiments, communication between a casino server anda gaming device may be secure. For example, a message sent from a gamingdevice to a casino server may be encrypted with the gaming device'ssecret key. According to some embodiments, a gaming device may generatean authentication code and transmit this authentication code to a casinoserver. Alternatively, communication between a gaming device and acasino server may not be encrypted or may not be secure.

A casino server may store at least one secret key. Examples of secretkeys that may be stored by a casino server include:

-   -   (i) A casino server may store a first secret key for a first        gaming device and a second secret key for a second gaming        device.    -   (ii) A casino server may store at least one first secret key for        communicating with gaming devices and a second secret key for        generating an authentication code.    -   (iii) A casino server may store a plurality of public keys        corresponding to a plurality of private keys stored by gaming        devices.    -   (iv) A casino server may store a secret key used for generating        an authentication code.

According to some embodiments, generating an authentication code for aplurality of gaming devices may include a step of receiving usage datafrom a plurality of gaming devices. According to some embodiments, acasino server may aggregate usage data from a plurality of gamingdevices. Examples include:

-   -   (i) A casino server may determine a total coin-in for a        plurality of gaming devices by summing the coin-in values from        each of the gaming devices.    -   (ii) A casino server may determine a net profit for a plurality        of gaming devices by summing the revenues from each gaming        device and subtracting any costs associated with operating the        plurality of gaming devices.    -   (iii) A casino server may determine an average credit balance        for a plurality of gaming devices and/or a subset of gaming        devices associated with a particular licensing/leasing        agreement.    -   (iv) A casino server may determine a median session length for a        plurality of gaming devices.    -   (v) A casino server may determine a standard deviation or        variance in theoretical win for a plurality of gaming devices.        Note that a variety of other aggregations of usage data are also        possible. Information determined by aggregating usage data from        a plurality of gaming devices may be known as “aggregated usage        data.”

According to some embodiments, a casino server may generate anauthentication code and output this authentication code in a mannersimilar to that described above. Note that an authentication code mayinclude usage data from a plurality of gaming devices or aggregatedusage data from a plurality of gaming devices.

According to some embodiments, a casino may provide consideration to aninterested party based on usage data or an authentication code. Forexample, a casino may pay a leasing fee to a game manufacturer based onwhat features are activated on a gaming device.

According to some embodiments, an interested party may provideconsideration to a casino based on usage data or an authentication code.For example, an advertiser may pay a fee to a casino based onadvertisements viewed on a gaming device.

According to some embodiments, a player may provide consideration to aninterested party based on usage data or an authentication code. Forexample, a player may pay a fee to a casino based on his usage of aportable gaming device.

According to some embodiments, an interested party may provideconsideration to a player based on usage data or an authentication code.For example, a player may receive a free hotel room for a night based onhis usage of a new type of gaming device.

Examples of interested parties include: regulatory groups, gamemanufacturers, subsidizers, and licensors.

Various types of consideration are possible, including money, products,and services. Various methods of determining an amount of considerationare known to those skilled in the art, including a formula or arules-based system.

In some embodiments, a gaming device, casino server, authenticationserver or other device may determine an interested party based on usagedata or an authentication code. For example, a casino server maydetermine one or more subsidizers to provide payments based on usagedata or an authentication code from a gaming device. In a secondexample, an authentication server may determine what local taxes areowed (e.g. Nevada, but not California) based on game play using aportable gaming device.

According to some embodiments, the present invention may be used totrack usage data relating to a player. For example, a casino or otheraggregator of gaming devices may desire to implement a comp system thatmotivates players to use gaming devices. Traditionally, such compsystems are implemented by connecting a plurality of gaming devices to acasino server that tracks player activities on the gaming devices.However, for some casinos, it may be costly or impractical to implementsuch a comp system. For example, a “casino” (as defined above) mayoperate gaming devices in a plurality of grocery stores, bars, shoppingmalls, and other retail establishments in the state of Nevada. For thiscasino, a networked comp system is inappropriate and is typicallyomitted. Not having a comp system on these machines is a detriment toboth the players who play these gaming devices (i.e., because they donot receive comps), and to the “casino” (i.e., players may play thegaming devices less often because no comps are provided).

According to some embodiments, an authentication code may be output to aplayer of a gaming device. This authentication code may include varioususage data, may be determined in a variety of different ways and may beoutput in a variety of different ways. For example, a gaming device mayprint out a receipt for a gaming session that includes one or more ofthe following:

-   -   (i) an indication of the player (e.g., a player identifier        obtained from a player tracking card)    -   (ii) an indication of a gaming device    -   (iii) usage data relating to the gaming session (e.g., session        coin-in, session theoretical win)    -   (iv) an authentication code (e.g., including information        sufficient to verify the player's usage of the gaming device)        In a second example, an authentication code may be stored on        player tracking card. For example, a player may carry a smart        card that identifies the player and functions as a player        tracking card. Information about the player's usage of at least        one gaming device may be included in an authentication code and        the authentication code may be stored on the smart card.

A player may use an authentication code to obtain a comp (i.e.,complimentary) or other benefit in a variety of different ways. Forexample, a player may take his receipt, smart card, or other indicationof an authentication code to a cashier (e.g., a customer serviceemployee at supermarket or shopping mall). The cashier may then use theauthentication code to verify the player's usage data. If theauthentication code and usage data are verified, then the player mayreceive an appropriate comp or other benefit.

In another example, a player may operate a terminal device (e.g., akiosk) to register himself for a comp. For example, a player mayidentify himself (e.g., by inserting his player tracking card into thekiosk) and use a bar code reader (i.e., an input device) to scan anauthentication code that is printed on a receipt. Based on theauthentication code, a comp may be provided to the player.

In another example, a player may visit a website (e.g. a website of agaming device manufacturer or other interested party) and indicate anauthentication code using the website. Based on the authentication code,a comp may be provided to the player (e.g., through the website).

A variety of different types of comps may be provided to players, as isknown in the art. Examples of comps include money, alternate currencies(e.g. comp points), products, services, and other forms ofconsideration. Note that a comp may be provided to a player by a casino,by a gaming device manufacturer, or by some other interested party.

Note that by providing an authentication code obtained at a gamingmachine, a player may authenticate both his own usage of the gamingdevice and other usage data relating to the gaming device. For example,in addition to including information about a player's usage of a gamingdevice, a gaming receipt that is output to a player may also include anauthentication code that includes information about the year-to-datecoin-in at that gaming device. As described above, this information maybe useful in verifying the authenticity of gaming device usage data toone or more interested parties (e.g., a gaming device manufacturer)

According to some embodiments, a gaming device may receive an indicationof an activation code (e.g. from a casino server or an authenticationserver). Based on this indication, the gaming device may activate ordeactivate at least one feature on the gaming device.

According to some embodiments, an activation code may be an alphanumericcode, sequence of digits, digital certificate, or other informationsuitable for indicating that a feature or a gaming device should beenabled or disabled. According to some embodiments, activation codes maybe particularly appealing to casinos because they allow casinos toenable or disable features as they see fit (e.g., to provide the bestpossible entertainment experience for players, or to reduce licensingcosts).

Applicants have recognized that a casino may alter the operation of agaming device (e.g., by using an activation code to enable a feature)and then deny that it altered the operation of the gaming device. Forexample, a casino may activate a 3D graphics feature on a gaming devicethat is particularly entertaining to players. According to an existingagreement, a casino may be required to pay a game manufacturer a licensefee to use this 3D graphics feature on the gaming device. As describedabove, a gaming device may track usage of this feature so as todetermine an appropriate license fee to be paid to the gamemanufacturer. However, at the end of a month, when it is time for thecasino to play a license fee based on usage of the 3D graphics feature,the casino may deny that it activated the feature. For example, a casinoexecutive may say, “The gaming device must have activated the 3Dgraphics feature itself. We didn't activate the feature. Therefore, werefuse to pay the licensing fee.” Needless to say, a game manufacturer,licensor, or other interested party would like to avoid such asituation.

According to some embodiments, a casino may need to contact aninterested party (e.g. a game manufacturer) or a trusted third party inorder to obtain an activation code. Alternatively, a casino may generateits own activation code (e.g. using a casino server). According to someembodiments, an activation code may be digitally signed by a casino.That is, an activation code may include a digital signature that canonly be produced using a private key that is known only to the casino.For example, a casino may operate a casino server or other device thatis used to activate or deactivate feature(s) on at least one gamingdevice. This casino server may store a private key that is known only tothe casino. Whenever the casino would like to activate or deactivate afeature, a casino employee may indicate this to the casino server (e.g.by using an input device attached to the casino server). The casinoserver may then determine an activation code appropriate for activatingor deactivating the feature on the gaming device.

An activation code generated by a casino server may include informationsuch as:

-   -   (i) feature—An indication of what feature or features should be        activated or deactivated.    -   (ii) action to be performed—(e.g., “activate” or        “deactivate”)—An indication of what action should be performed        on the indicated feature or features.    -   (iii) gaming device—An indication of what gaming device or        machines the activation code is intended for.    -   (iv) time—An indication of when the activation code is        generated. Note that including an indication of time in an        activation code may prevent a casino from claiming that a gaming        device is reusing an old activation code.    -   (v) operator—An indication of who is operating the casino server        (i.e., who requested that the casino server generate the        activation code). This information may be helpful in allowing a        casino to determine what employee activated a feature. Note        that, according to some embodiments, a casino server may        activate a feature automatically based on a condition (e.g. a        feature may be activated every day from 6 pm-9 pm).        Various other information that may be included in an activation        code is analogous to information that may be included in an        authentication code, as described above.

A casino server may sign an activation code using a private key. Methodsof producing digital signatures are known to those skilled in the artand are similar to methods used for generating an authentication code(as described above). Note that signing an activation code with aprivate key may include encrypting a portion of the activation code withthe private key (e.g., according to a public-key encryption algorithmsuch as the ones described above). One major benefit of signing anactivation code with a casino's private key is that nobody but thecasino should know this private key and be able to sign the activationcode with it. Therefore, there should be no way for anybody other thanthe casino to activate or deactivate a feature on the gaming device.According to some embodiments, a casino server may use the same privatekey to sign activation codes for a plurality of gaming devices.Alternatively, a casino server may store a plurality of private keys(e.g., one for each gaming device). The activation code may then beindicated to the gaming device. For example, a casino server maytransmit an indication of an activation code to at least one gamingdevice using a communication network. In another example, a casinoserver may output an activation code using an output device (e.g., avideo monitor, a disk drive). A casino employee may then provide thisactivation code to a gaming device using an input device (e.g., anumeric keypad, a magnetic stripe reader).

According to some embodiments, a gaming device may verify an activationcode. Various methods are possible depending on how an activation codewas generated. For example, a casino server may sign an activation codewith a private key. A gaming device may then verify this activation codewith a public key corresponding to the private key. According to someembodiments, a plurality of gaming devices may store the same public keyfor a casino server. Alternatively, each gaming device may store adifferent public key (e.g., because a casino server uses a differentprivate key for each gaming device).

A gaming device may activate or deactivate a feature based on anactivation code that is received and verified. As described above, usagedata tracked by a gaming device and included in an authentication codemay include information about activating or deactivating features and/orinformation about activation codes that are indicated to a gamingdevice. Including information about activation codes in anauthentication code is one way of communicating an activation code to aninterested party and preventing a casino from denying that it activateda feature on a gaming device. Other means of authenticating usage data(e.g., as described above) may also be used to authenticate that acasino provided an activation code.

Usage data for a gaming device may be monitored and authenticated usingan auxiliary device. For example, an auxiliary device may be attached tothe side of a gaming device and used to perform the following steps:

-   -   (i) determining usage data relating to a gaming device    -   (ii) generating an authentication code based on the usage data    -   (iii) outputting the authentication code        Note that these steps may be performed in a manner similar to        that described above for a gaming device. An auxiliary device        may include one or more of the following:    -   (i) a processor    -   (ii) memory (e.g. storing a secret key)    -   (iii) an input device    -   (iv) an output device    -   (v) a communication port    -   (vi) a secure perimeter        An auxiliary device may be situated in various locations,        including:    -   (i) attached to the outside of a gaming device—For example, an        auxiliary device 2400 may be encased in a stainless steel box        that may be bolted to the back of a gaming device 1300. One        example of this embodiment is shown in FIGS. 24A and 24B. Note        that the example auxiliary device 2400 depicted in FIGS. 24A and        24B includes a camera 2402 that may determine when the reels of        a slot machine are spinning.    -   (ii) proximate to a gaming device—For example, an auxiliary        device may be attached to the ceiling above a gaming device and        include a camera that allows the auxiliary device to monitor        game play at the gaming device.    -   (iii) inside a gaming device—For example, an auxiliary device        may be a component of a gaming device that is connected to the        electronics of the gaming device by at least one wire or        channel.

According to some embodiments, an auxiliary device 2400 may communicatewith a gaming device (e.g., to receive information relating to usagedata). For example, an auxiliary device 2400 may be connected to theprocessor of a gaming device and receive indications of usage datarelating to the gaming device. In a second example, an auxiliary devicemay read information from a memory, a data storage device, and/orcommunications port on a gaming device.

According to some embodiments, an auxiliary device 2400 may include atleast one sensor or input device. This sensor may enable to theauxiliary device to monitor a gaming device and independently determineor confirm usage data. Details of different types of sensors and inputdevices are described above.

Examples of Sensors that May be Included on an Auxiliary Device Include:

-   -   (i) a camera aimed at the front of a gaming device. A camera may        be used to independently determine information such as a bet        that is placed on the gaming device, a credit balance on the        gaming device, or an outcome on the gaming device.    -   (ii) a motion sensor may determine when the reels of a slot        machine are spinning.    -   (iii) a proximity sensor may identify when there is a person        standing or sitting in front of a gaming device.    -   (iv) a weight sensor may determine how many coins are in the        hopper of a gaming device

According to some embodiments, the invention may include a kit thatenables a party to add an auxiliary device 2400 to a gaming device 1300or otherwise modify a gaming device to generate an authentication codebased on usage data.

It is clear from the foregoing discussion that the disclosed systems andmethods for authenticating gaming device usage data represents animprovement in the art of gaming. While the method and apparatus of thepresent invention has been described in terms of its presently preferredand alternate embodiments, those skilled in the art will recognize thatthe present invention may be practiced with modification and alterationwithin the spirit and scope of the appended claims. The specificationsand drawings are, accordingly, to be regarded in an illustrative ratherthan a restrictive sense.

Further, even though only certain embodiments have been described indetail, those having ordinary skill in the art will certainly appreciateand understand that many modifications, changes, and enhancements arepossible without departing from the teachings thereof. All suchmodifications are intended to be encompassed within the followingclaims.

1. A method comprising: determining a measure of usage of a first feature on a first gaming device; determining a measure of usage of a second feature on the first gaming device; determining a first payment rate that is associated with a first party; determining a first payment amount based on the first payment rate and the measure of usage of the first feature; determining a first code based on the measure of usage of the first feature; initiating payment of the first payment amount to the first party; outputting the first code for transmission to the first party; determining a second payment rate that is associated with a second party; determining a second payment amount based on the second payment rate and the measure of usage of the second feature; determining a second code based on the measure of usage of the second feature; initiating payment of the second payment amount to the second party; and outputting the second code for transmission to the second party. 